Information Security and Data Protection Policies

1. Scope, roles and definitions

Systems in scope. The TD Dashboards platform: data pipelines running on AWS Lambda (region eu-west-1), a Postgres warehouse and authentication service on Supabase, API functions on Supabase Edge Functions, static dashboards on Cloudflare Pages, source code on GitHub, error reporting on Sentry, and the laptops staff use to reach them. The platform reads Amazon Selling Partner API (SP-API) and Amazon Ads API data for TD Nutrition Ltd's own seller accounts only.

Amazon Information means any data obtained through Amazon APIs or Seller Central, as defined in Amazon's Acceptable Use Policy and Data Protection Policy. PII means information that identifies a natural person (for example a buyer's name, address, email or phone number).

Roles

All staff with access confirm they have read these policies when access is granted and at each annual review.

2. Control implementation status

3. Data handling and privacy policy

3.1 Classification

3.2 Collection and purpose

We collect Amazon Information only for our own seller accounts, through the SP-API and Amazon Ads API, for these purposes: sales and profit reporting, inventory and supply planning, advertising management, listing quality, account health monitoring, VAT and EPR compliance, and support-case tracking. Data is not used for any other purpose, is not sold, and is not used to build profiles of buyers.

3.3 Personally identifiable information

• Our applications do not request buyer PII from the Orders API; order records hold the order ID, amounts, status, item counts and marketplace only.
• The one report that can contain buyer details (VAT transaction data) is parsed for tax and amount columns only; buyer columns are discarded before anything is written to storage.
• Support-case data (if the Selling Partner Support role is granted) consists of our own correspondence with Amazon; any incidental PII in case text is retained only as long as the case is open plus 30 days, then deleted, unless a legal obligation requires longer.
• If PII is ever required for a defined purpose, it will be retained no longer than 30 days after order shipment, except where law requires longer retention (for example tax records), and this policy will be updated first.

3.4 Storage and location

Data is stored in Supabase (Postgres, hosted on AWS eu-west-1, Ireland) and AWS (eu-west-1, Ireland). Both encrypt data at rest with AES-256 and in transit with TLS 1.2 or higher. Backups are encrypted. No Amazon Information is stored on laptops, removable media or personal devices.

3.5 Sharing and sub-processors

Amazon Information is not shared with third parties, not disclosed to other developers, and not transferred to other Amazon developer applications. The following providers host or process it on our behalf under their standard data processing terms:

3.6 Retention and disposal

• Business records (orders without PII, financial, inventory, advertising): retained for 7 years to meet UK and EU tax law, then deleted.
• Audit logs: at least 12 months, pruned after 25 months (database) or 400 days (CloudTrail).
• Credentials: rotated at least every 180 days; superseded values are overwritten in the vault, never archived.
• Disposal is by deletion in the provider's console or by scheduled database jobs; cloud providers wipe underlying storage per their certified procedures. Staff laptops are encrypted and are securely erased before reuse or disposal.

3.7 Data subject rights and law

TD Nutrition Ltd complies with the UK GDPR and the EU GDPR. Requests from individuals are sent to contact@tdnutrition.eu and answered within one month. Because buyer PII is not stored by these systems, such requests are normally fulfilled through Amazon's own processes.

4. Record of processing activities

5. Access control and password policy

5.1 Principles

• Individual accounts only. Every person has a named account (business email). Shared accounts are prohibited. One sealed emergency ("break-glass") credential exists for the dashboards; its use is logged and triggers a password change.
• Least privilege and need to know. Access is granted per system and per role (admin, viewer, analyst, PPC manager with market restrictions). A new role is a database row approved by the Director, recorded in the audit log.
• Joiners, movers, leavers. Access is requested by the Director in writing (email or ticket), granted within one working day, and removed within 24 hours of a role change or departure. Removal covers Supabase Auth, role tables, GitHub, AWS IAM and Google Workspace.
• Review. Active accounts and their last sign-in appear in every fortnightly security review; accounts unused for 90 days are flagged and disabled unless justified.
• Service credentials are scoped to one function and one purpose (for example a token that can only write repository secrets), stored in AWS Secrets Manager or the platform secret store, and never shared between services.

5.2 Passwords and MFA

• Dashboards (Supabase Auth): minimum 12 characters, containing lower-case, upper-case, digits and symbols; stored hashed with bcrypt; no reuse of the previous password; rate-limited sign-in; session tokens expire and are refreshed automatically.
• AWS (root and IAM users), GitHub and Supabase: multi-factor authentication is mandatory. AWS IAM access keys are rotated at least annually; unused keys are deleted.
• Passwords are never written down, shared, or sent by email or chat. Staff use a password manager.
• Expiry and rotation: every password used to reach Amazon Information expires after 365 days. Dashboard sign-in is refused by an authentication hook when the password is older than 365 days, until the user sets a new one through the password-reset flow; the date each password was set is recorded automatically. Console and root credentials (AWS, GitHub, Supabase, Seller Central) are rotated at least annually by hand and the rotation date recorded in the credential register; the fortnightly review warns 30 days before a rotation is due and flags any overdue credential. A password is changed immediately if it is suspected to be compromised.

6. Change management policy

• All production changes go through a pull request on the main branch of the repository. Direct pushes, force pushes and branch deletion are blocked by branch protection with no bypass.
• Testing. Every pull request must pass the automated checks: syntax and undefined-name lint, secret scan, dependency vulnerability scan, static security analysis and rule-based code analysis. Changes to pipelines include unit tests under tests/. Database changes are written as versioned migration files; the staging check applies them to the staging project when the pull request is opened, and migrate-prod applies the same files to production after the merge, each in one transaction.
• Approval and release. Only the Director may merge to main. The merge is the approval record (author, reviewer, time, checks). Merging triggers deployment of dashboards and API functions; AWS stacks are deployed by the Director with CloudFormation change sets that are confirmed interactively.
• Separation of duties. Automated tooling (including AI-assisted development) may prepare a change, but may not merge or deploy it; the Director reviews the diff and the check results before merging.
• Rollback. A faulty change is reverted with a new commit through the same process; history is never rewritten. AWS stacks roll back automatically on failed deployments.
• Emergency changes (an outage or active security incident) follow the same pull-request path; the only difference is that review happens immediately. The incident record references the pull request.
• Records. The pull-request history, CloudTrail (for AWS) and the audit log (for data changes made through the dashboards) together form the complete change record and are kept at least 12 months.

7. Vulnerability and patch management policy

Remediation targets

• Critical: fixed within 7 days. High: within 30 days. Medium: within 90 days. Low: at the next planned change.
• A finding that cannot be fixed in time is recorded in docs/security/exceptions.md with the reason, the compensating control, the owner and an expiry date, and is re-raised at every fortnightly review until closed.
• Progress is tracked through the pull request that fixes the finding (linked from the exception register) and verified by the next scan run.
• This policy does not currently include an external penetration test; the Director reviews this decision at each annual policy review.

8. Logging, monitoring and review policy

8.1 What is logged

8.2 Monitoring and alerting

• Pipeline failures, rotation failures and unexpected exceptions alert the Director through Sentry and push notification in real time.
• A watchdog reports pipelines that have not run successfully within their expected window.
• Account Health changes reported by Amazon are pushed to the Director's phone daily.

8.3 Fortnightly review

Every 14 days an automated job compiles the review: notable AWS events (console sign-ins, root use, IAM, secret, Lambda and logging changes), IAM users and key ages, authentication events and new accounts, dashboard actions per user, rejected requests per IP address, new user and IP combinations, credential rotations and secret ages, and pipeline failures. It lists the items that need a human decision. The Director reads the report in Operations > Security and signs it off; the sign-off (who, when, notes) is stored permanently in security_review. Items needing action become a ticket or a pull request. A review that is not signed off within 7 days is shown in red on the dashboard.

9. Incident response plan

Roles. Incident Manager: the Director (Konstantin Theodoridis, contact@tdnutrition.eu), who declares the incident, leads containment and makes all external notifications, including to Amazon. Technical responder: the Director or the engineer on duty, who executes containment and recovery steps and preserves evidence. Communications with Amazon, regulators and affected individuals: the Director.

9.1 Severity

9.2 Steps

1. Detect and record. Open an incident record (date, time, reporter, what is known). Preserve logs: do not delete anything.
2. Contain. Revoke the affected sessions and accounts; rotate every credential that could be involved (LWA client secrets through the rotation function, SP-API and Ads refresh tokens by re-authorising the apps, database password, service-role and anon keys, AWS access keys, GitHub tokens); block the offending IP address at the provider where possible; take a compromised laptop offline.
3. Assess. Use CloudTrail, the dashboard audit log and the authentication log to establish what was accessed, by whom, from where and when, and whether Amazon Information or personal data was involved.
4. Notify. If Amazon Information or the Amazon application is involved, notify Amazon at security@amazon.com within 24 hours of discovery, with the incident details, and cooperate with Amazon's requests. If personal data is involved, assess the risk and notify the ICO (UK) and the Hellenic DPA where required within 72 hours, and affected individuals without undue delay when the risk is high.
5. Eradicate and recover. Remove the cause (patch, configuration change, revoke access), restore data from backup if integrity is in doubt, and confirm from the logs that the activity has stopped.
6. Learn. Within 10 working days write a post-incident report: timeline, root cause, data affected, actions taken, and policy or control changes. File it under docs/security/incidents/ and review it at the next fortnightly review.

9.3 Testing

The plan is reviewed every six months (May and November) by the Director, walked through at least once a year as a tabletop exercise (scenario: leaked database credential), and reviewed again after any real incident. Each review is recorded in the fortnightly security review in the dashboard.

10. Backup and business continuity policy

• Primary backups. The database provider takes daily automated encrypted backups of the warehouse (retention per plan, at least 7 days).
• Independent, geographically separate copy. A nightly logical dump of the warehouse is encrypted with AWS KMS and written to an S3 bucket in a different AWS region (eu-central-1, Frankfurt) from the primary systems (all in eu-west-1, Ireland), with versioning, no public access and a 90-day lifecycle. GitHub Actions uploads it through a short-lived OIDC role; no AWS keys are stored in GitHub.
• Objectives. Recovery point objective (RPO): 24 hours. Recovery time objective (RTO): 4 hours for the warehouse and dashboards, because the pipelines re-pull recent data from Amazon on their next run.
• Restore procedure. Documented in the repository (infra/stacks/backup/README.md): create a new database or project, restore the latest dump with pg_restore, update the connection secret, run the data-coverage report to confirm freshness, redeploy functions. The procedure is tested quarterly by restoring into a scratch project, and the test is recorded in the fortnightly review.
• Code and configuration are in Git (GitHub, with the Director's local clone as a second copy). Infrastructure is defined as code (CloudFormation/SAM) and can be redeployed from the repository.
• Credentials needed for recovery are in AWS Secrets Manager; the AWS root credentials and MFA recovery codes are kept offline by the Director.

11. Credential and secrets management policy

• Secrets (API keys, tokens, passwords, private keys) live only in AWS Secrets Manager, GitHub encrypted secrets or the Supabase secret store. They are never committed to source code, written in documents or sent by email or chat. A secret scanner runs on every change and blocks a leak; a leaked secret is rotated the same day.
• Amazon LWA client secrets are rotated automatically before Amazon's 180-day limit by the td-lwa-rotation function, which distributes the new secret to every store that needs it and verifies it works. Each step is logged.
• Access tokens issued to automation are scoped to the minimum permission (for example a repository token limited to writing secrets, a database token limited to function secrets), named after their purpose, and given an expiry of at most one year.
• Credentials are revoked immediately when the service that used them is retired or a person leaves.
• The public keys used by browsers (the Supabase anonymous key, the Web Push public key) are not secrets; the controls that protect data are row-level security and server-side authorisation, not the secrecy of these keys.

12. Endpoint and device policy

• Amazon Information is accessed only through the authenticated web dashboards and is not downloaded to, stored on or synchronised to laptops, phones, USB drives or personal cloud storage. Exports for accountants contain tax and amount data only.
• Laptops used for administration have full-disk encryption (FileVault), automatic operating system updates, a screen lock after 5 minutes, and a firewall enabled. Administrative consoles (AWS, Supabase, GitHub, Seller Central) are used only from these laptops with MFA.
• Personal devices may be used to receive alerts and to view the dashboards in a browser; they may not hold credentials or exported data.
• Lost or stolen devices are reported to the Director immediately; sessions are revoked and the device is remotely erased where supported.
• Staff are briefed on phishing and credential hygiene at onboarding and whenever a relevant incident occurs.

13. Contacts

Incident Management Point of Contact (IMPOC): Konstantin Theodoridis, Director, contact@tdnutrition.eu.

Privacy enquiries: contact@tdnutrition.eu.

Registered office: TD Nutrition Ltd, 20-22 Wenlock Road, London N1 7GU, United Kingdom.