How Swapt protects your data

1. Purpose

This policy sets out how Swapt protects the confidentiality, integrity and availability of the information we hold. That includes our customers' (sellers') data, the data of buyers who opt in through sellers' Swapt pages, and data we receive from partner platforms such as TikTok Shop, Shopify and Amazon.

2. Scope

This policy covers:

• The Swapt web application, its APIs, background workers and databases.
• Cloud infrastructure: Google Cloud Platform (application hosting and PostgreSQL database), Cloudflare (storage, CDN and network protection), Amazon Web Services (CloudFront and SES email delivery) and Temporal (background job orchestration).
• Company accounts: Google Workspace, GitHub, cloud consoles and other SaaS tools.
• Company laptops and any device used to access Swapt systems or data.
• Everyone with access to the above: employees, contractors and service providers.

3. Roles and responsibilities

• Security Owner (Andrew Smith). Owns this policy and the supporting standards. Approves access to production systems, leads incident response, runs access reviews and tracks vulnerabilities to closure.
• Engineers. Follow secure development practices, keep dependencies up to date, and report suspected security issues immediately.
• All personnel. Follow this policy, protect their credentials and devices, and report suspected incidents to the Security Owner without delay.

4. Policy statements

Swapt maintains the following supporting standards. Each one is part of this policy and is binding.

Area	Supporting document
Network security, environment isolation and perimeter protection	Network Security and Environment Isolation Standard
Anti-malware and endpoint protection	Endpoint Protection Standard
Workstation and account security baseline	Security Baseline Standard
Access control and least privilege	Access Control Policy
Data classification and encryption	Data Classification and Encryption Policy
Incident response	Incident Response Plan
Vulnerability and patch management	Vulnerability and Patch Management Procedure
Personal data protection, data subject requests and retention	Personal Data Protection Policy

In summary:

1. Least privilege. People and systems get only the access they need. Production access is limited to named engineers and is reviewed every quarter.
2. Strong authentication. Multi-factor authentication is required on Google Workspace, GitHub, Google Cloud, AWS, Cloudflare and every other administrative console.
3. Encryption. All traffic between users, partners and Swapt is encrypted with TLS 1.2 or higher, and all stored data is encrypted at rest. Partner API credentials, such as TikTok Shop access and refresh tokens, are additionally encrypted by the application with AES-256.
4. Data minimization. We collect and keep only the data the service needs. From TikTok Shop we read only product, SKU and order-status data. We do not read buyer names, addresses or contact details from TikTok Shop, and we use TikTok Shop data only to provide the service to the seller who authorized it.
5. Environment separation. Development and test environments are separate from production and never contain production personal data.
6. Secure development. All code changes go through pull requests with review before release. Secrets are kept out of source code.
7. Monitoring. Application errors and performance are monitored continuously with Sentry and platform logs.
8. Vulnerability management. Dependencies are checked for known vulnerabilities and patched within defined timeframes.
9. Incident response. Incidents are handled under the Incident Response Plan. Affected sellers and partners, including TikTok Shop, are notified without undue delay and within 72 hours of confirming a breach that involves their data.
10. Vendor management. We use only reputable infrastructure providers that maintain recognized security certifications (such as SOC 2 and ISO 27001), and we review their security posture when we adopt them.
11. Data subject rights and retention. We help sellers and partners respond to requests to access, correct or delete personal data. When a seller's contract ends, we revoke their partner tokens immediately and delete their customer data within 30 days, unless the law requires us to keep it.

5. Personnel security

• Everyone with system access acknowledges this policy when they join and after each annual update.
• Access is removed on the day a person leaves or no longer needs it.
• Personnel receive security awareness guidance when they join and at least once a year, covering phishing, credential handling and incident reporting.

6. Compliance and exceptions

Breaking this policy may lead to access being removed and disciplinary action. Any exception must be approved in writing by the Security Owner, with an expiry date and compensating controls, and is recorded in the security log.

7. Review

The Security Owner reviews this policy and every supporting standard at least once a year, and after any significant incident or change to our infrastructure.

1. Architecture overview

• Application. The Swapt application runs as containers on Google Cloud App Engine (flexible environment), a managed platform. Google operates and patches the underlying hosts and network, and no Swapt staff have shell access to production hosts.
• Database. Production data is stored in a managed PostgreSQL database on Google Cloud SQL, with automated daily backups. Access requires dedicated database credentials, held only in the production platform's secret configuration.
• Edge. Public traffic reaches Swapt only over HTTPS through managed edge networks (Google Cloud load balancing, Amazon CloudFront and Cloudflare). These provide TLS termination and DDoS mitigation.
• Storage. Files and images are stored in Cloudflare R2 object storage. Access requires API keys held only by the application.
• Background work. Scheduled and long-running jobs run on Temporal, over authenticated and encrypted connections.

2. Environment isolation

• Production, development and test environments are fully separate. Each has its own database, credentials and configuration.
• Development runs on engineers' encrypted laptops against local databases. Automated tests run against a throwaway local database with dummy credentials.
• Production personal data is never copied into development or test environments.
• Production credentials are stored only in the production platform's secret configuration. They are never committed to source control, and they are available only to the people listed in the access register (see the Access Control Policy).

3. Network segmentation and perimeter protection

• All user and partner traffic is served over HTTPS only. HTTP requests are redirected to HTTPS, and HTTP Strict Transport Security (HSTS) is enabled.
• Administrative access to cloud resources happens only through the providers' consoles and CLIs, which require MFA, and is limited to the people listed in the access register.
• Inbound webhooks from partners (TikTok Shop, Shopify) are accepted only after their signatures are verified.
• The application enforces rate limits on login, password reset, magic links and public endpoints to slow brute-force and abuse attempts.
• Session cookies are HTTP-only, Secure and SameSite=Lax. Pages cannot be framed by other sites (X-Frame-Options: DENY), and browsers are told not to guess content types.

4. Monitoring and threat detection

• Application errors and unusual failures are captured in Sentry and alert the engineering team.
• Platform request logs and audit logs from Google Cloud, AWS and Cloudflare record administrative actions and traffic, and are reviewed when investigating suspicious activity.
• Cloudflare and CloudFront provide automatic DDoS protection at the edge.
• Suspected network threats are handled under the Incident Response Plan.

5. Review

The Security Owner reviews network and firewall settings, including database network access rules, every quarter and after any infrastructure change, and records the review in the security log.

1. Scope and coverage

This standard applies to every laptop or desktop used to access Swapt systems, source code or data ("endpoints"). Swapt personnel work on company Apple Mac computers running a supported version of macOS. Coverage is 100% of these endpoints. A device that doesn't meet this standard may not be used to access Swapt systems.

2. Anti-malware protection

Every endpoint runs Apple's built-in, always-on malware protection, which cannot be turned off by ordinary use:

• XProtect scans applications and files for known malware when they are opened or changed. Its signatures update automatically and independently of macOS updates.
• XProtect Remediator scans in the background on a regular schedule and removes known malware it finds.
• Gatekeeper and notarization block software that isn't signed by an identified developer and checked by Apple, unless a user explicitly overrides it.
• System Integrity Protection stops malicious software from changing protected system files.

Gatekeeper and System Integrity Protection must stay enabled. Users must not override malware warnings.

3. Updates

• Automatic macOS updates are enabled, including "Install Security Responses and system files", so XProtect signatures and Rapid Security Responses install automatically.
• Critical macOS security updates are installed within 7 days of release, and other security updates within 30 days.
• Browsers and development tools are kept on supported versions with auto-update turned on.

4. Device hardening

• FileVault full-disk encryption is enabled on every endpoint.
• The macOS firewall is enabled.
• Screen lock settings follow the Security Baseline Standard.
• Software is installed only from the Mac App Store, identified developers or official package managers.

5. Verification

• When a device is first given to someone, the Security Owner checks that FileVault, Gatekeeper, System Integrity Protection, the firewall and automatic updates are turned on.
• Every quarter, each person confirms these settings on their device, and the Security Owner records the result in the security log.
• Any device that falls short is fixed before it is used again for Swapt work.

6. Lost or stolen devices

A lost or stolen device must be reported to the Security Owner immediately. The device is remotely locked or wiped through Find My, the user's account sessions and tokens are revoked, and the event is handled under the Incident Response Plan.

1. Screen lock and workstation security

• Screens lock automatically after no more than 5 minutes of inactivity, and a password or Touch ID is required to unlock.
• People lock their screen whenever they step away from their device.
• FileVault full-disk encryption is enabled on every device (see the Endpoint Protection Standard).
• Clear desk: customer data, credentials and printed confidential material are not left unattended or visible, and screens are not shared in public places while confidential data is on them.

2. Password requirements

• Company accounts use unique passwords of at least 12 characters, generated and stored in an approved password manager.
• Passwords are never reused between accounts, shared by email or chat, or written down.
• Shared service credentials are stored only in the password manager or the production platform's secret configuration, and are rotated when someone with access leaves.
• In the Swapt application, every new password must be at least 8 characters. Passwords are hashed with scrypt, a slow, salted algorithm, and are never stored or logged in plain text.

3. Multi-factor authentication

MFA is required and enforced on every company account that can reach systems or data:

System	MFA
Google Workspace (email and documents)	Required
GitHub (source code)	Required
Google Cloud (application and database)	Required
Amazon Web Services	Required
Cloudflare	Required
Temporal and other administrative consoles	Required

Approved methods are authenticator apps, security keys and passkeys. SMS is used only where nothing else is available.

4. Swapt application accounts

• The application rate-limits login, password reset and magic-link requests to block brute-force and credential-stuffing attacks. It answers sign-in requests the same way for unknown emails, so attackers cannot discover which accounts exist.
• Session cookies are HTTP-only, Secure and SameSite=Lax.
• Internal administrative ("super admin") access requires signing in with an allowlisted company Google account. Google Workspace 2-Step Verification provides the second factor, and the shared password form is disabled.
• When a staff member signs in as a seller to give support, the session is flagged as impersonation.
• Multi-factor authentication for seller logins to the Swapt application is on our product roadmap.

5. Account lifecycle

• Accounts are created only with the Security Owner's approval and are tied to a named person. Shared personal logins are not allowed.
• Access is removed on the day a person leaves (see the Access Control Policy).

1. Principles

• Least privilege. People and services get only the minimum access their role needs, for only as long as they need it.
• Need to know. Personal data, including any data received from TikTok Shop, is accessed only to provide or support the service for the seller who authorized it.
• Named accounts. Every account belongs to one identified person or service. Shared personal logins are not allowed.
• Authentication. Every administrative account requires MFA (see the Security Baseline Standard).

2. Role-based access: internal systems

Role	Who	Access
Security Owner / Administrator	Andrew Smith	Administrative access to cloud consoles, production configuration and the database; approves all access
Engineer	Named engineering staff	Source code; production deploys through the approved pipeline; production data only when needed to investigate an incident or support request
Support / Operations	Named staff	The Swapt admin interface for assigned seller accounts; no direct database or infrastructure access
Contractors	As approved	Time-limited, scoped to the specific task, removed when the task ends

The Security Owner keeps a register of who holds production, database and cloud console access.

3. Role-based access: the Swapt application

• Tenant isolation. Each seller's data belongs to their organization. Every application query is scoped to the signed-in user's organization, so one seller can never see another seller's data.
• Roles within a seller account. Account administrators can manage settings, users and integrations. Other users get the narrower roles, including view-only access, that their administrator assigns.
• Internal admin functions. Super-admin access requires signing in with one of a short allowlist of company Google accounts, with Google 2-Step Verification. There is no shared admin password.
• No anonymous access to data. Endpoints that hand out promo codes, prize files or customer form data require a signed-in session or the customer's own access token, and are limited to the caller's organization. Automated tests check these guards on every change.
• Least-privilege service accounts. Components get only the database permissions they need. For example, the reporting assistant uses a dedicated database role with read-only access to an approved set of tables and a statement time limit.
• Partner credentials. TikTok Shop access and refresh tokens are encrypted by the application and used only by the server to read product and order-status data for the authorizing seller. They are never shown in the user interface or logs.

4. Granting, changing and removing access

1. Access requests go to the Security Owner, stating the role and the reason.
2. The Security Owner approves the minimum access needed and records it in the access register.
3. When someone's role changes, the access they no longer need is removed.
4. When someone leaves, all their access is removed on their last day: Google Workspace, GitHub, cloud consoles, the password manager and the Swapt admin. Shared secrets they could see are rotated.

5. Access reviews

• Every quarter, the Security Owner reviews everyone with access to Google Cloud, AWS, Cloudflare, GitHub, the production database and the Swapt super-admin.
• Access that is no longer needed is removed immediately.
• Each review is recorded in the security log with its date, who reviewed it, what was found and what changed.

6. Logging

Administrative actions in Google Cloud, AWS, Cloudflare and GitHub are recorded in those providers' audit logs. Super-admin sign-ins to seller accounts are flagged in the application.

1. Data classification

Class	Examples	Handling
Restricted	Partner API credentials (TikTok Shop, Shopify, Amazon tokens), application secrets, password hashes, data received from partner APIs	Encrypted at rest, plus application-level encryption for credentials, so they stay encrypted wherever they are stored or sent internally; access limited to the application and the Security Owner; never logged or exported
Confidential	Personal data of buyers who opt in (name, email, phone if provided), seller account data, order references	TLS between users and Swapt; encrypted at rest; access limited to the owning seller and authorized staff; processed only to provide the service
Internal	Business documents, source code, configuration without secrets	Company accounts with MFA; not shared outside Swapt without approval
Public	Marketing website and published documentation	No restriction

Data from TikTok Shop is classified Restricted and used only to provide the service to the seller who authorized it. Swapt reads product, SKU and order-status data, and does not read buyer names, addresses or contact details from TikTok Shop.

2. Encryption in transit

• All traffic between users, partners and Swapt uses HTTPS with TLS 1.2 or higher. Plain HTTP is redirected to HTTPS, and HSTS tells browsers to connect only over HTTPS.
• All calls from Swapt to partner and provider APIs (TikTok Shop, Shopify, Amazon, AWS SES, Cloudflare R2, Temporal) use TLS.
• Session cookies carry the Secure flag, so browsers send them only over HTTPS.
• Email is delivered through AWS SES, which uses TLS to connect to receiving mail servers whenever they support it.

3. Encryption at rest

• Database. The production PostgreSQL database on Google Cloud, including its backups, is encrypted at rest with AES-256 by Google Cloud.
• File storage. Files in Cloudflare R2 are encrypted at rest with AES-256 by Cloudflare.
• Application-level encryption. Restricted credentials, including TikTok Shop access and refresh tokens and other integration secrets, are encrypted by the application with AES-256-CBC and an HMAC-SHA256 integrity check before they are written to the database. A database copy alone therefore does not reveal them.
• Passwords. User passwords are stored only as salted scrypt hashes.
• Endpoints. Every company laptop uses FileVault full-disk encryption.

4. Key management

• Encryption keys for data at rest in Google Cloud and Cloudflare are managed by those providers' key management services.
• The application encryption key is stored only in the production platform's secret configuration, not in source code, and is available only to the Security Owner.
• Keys and secrets are rotated if they may have been exposed, and when people with access to them leave.

5. Retention and disposal

• Personal data is kept only as long as the seller's account is active, or as the seller instructs.
• When a seller's contract ends, their partner tokens are revoked and deleted immediately, and their customer data is deleted within 30 days unless the law requires us to keep it.
• Requests to access, correct or delete a person's data are handled within 30 days.

1. Purpose and scope

This plan covers any event that threatens the confidentiality, integrity or availability of Swapt systems or data. Examples include unauthorized access, leaked credentials or tokens, malware, lost devices, data exposure, and service attacks or outages.

2. Roles and responsibilities

Role	Person	Responsibilities
Incident Commander	Andrew Smith	Leads the response; decides severity, containment and escalation; owns all external communication
Technical responders	Engineering staff	Investigate, contain, fix and recover; keep evidence
All personnel	Everyone	Report suspected incidents right away; never investigate or delete evidence on their own

If the Incident Commander can't be reached, the most senior available engineer takes the role until handover.

3. Reporting channels

• Internal. Anyone who suspects an incident reports it immediately to andrew@swaptqr.com and by phone or direct message to the Incident Commander.
• External. Sellers, partners and security researchers can report issues to andrew@swaptqr.com.
• Automated. Alerts from Sentry, Google Cloud, AWS and Cloudflare go to the engineering team.

4. Severity levels

Severity	Definition	Response target
Critical	Confirmed or likely exposure of Restricted or Confidential data (including TikTok Shop data), compromised production credentials, or a full outage	Respond immediately, within 1 hour
High	Suspected unauthorized access, a vulnerability being actively exploited, or a major feature unavailable	Within 4 hours
Medium	A contained security event with no evidence of data exposure	Within 1 business day
Low	Policy deviation or minor issue	Within 5 business days

5. Response procedure

1. Detect and report. Log the incident in the incident log with the time, who reported it, what was seen and the affected systems.
2. Triage. The Incident Commander assigns a severity and brings in responders.
3. Contain. Stop the damage from spreading. Steps can include:
   • revoking or rotating exposed credentials, API keys and partner tokens, including disconnecting affected TikTok Shop authorizations;
   • disabling compromised user accounts and ending their sessions;
   • blocking malicious IPs or traffic at the edge;
   • taking affected features offline;
   • isolating or wiping compromised devices.
4. Preserve evidence. Keep logs (application, Sentry, cloud audit logs) and snapshots before making destructive changes.
5. Eradicate. Remove the root cause, for example by patching the vulnerability, removing malicious code or fixing the misconfiguration.
6. Recover. Restore service from known-good deployments and backups, check data integrity, and watch closely for the problem coming back.
7. Escalate and notify (section 6).
8. Post-incident review. Within 10 business days of a Critical or High incident, write a review covering the timeline, root cause, impact and corrective actions. Track the actions to completion.

6. Escalation and notification

• Internal escalation. Critical and High incidents go to the Incident Commander immediately, and to company leadership within 1 hour.
• Sellers. Affected sellers are notified by email without undue delay, and within 72 hours of confirming a breach that involves their data. The notice describes what happened, the data involved, what we have done, and what they should do.
• TikTok Shop and other partners. If an incident involves data obtained through a partner's API, or that partner's credentials, we notify the partner through its designated security or partner support channel without undue delay, and within 72 hours of confirmation. If the partner requires a shorter timeframe, we meet it.
• Regulators and individuals. Where the law requires it (for example GDPR, CCPA or US state breach laws), we notify the relevant authorities and affected individuals within the legal deadlines.
• Law enforcement. We involve law enforcement where appropriate and as advised by legal counsel.

7. Records

Every incident is recorded in the incident log with its timeline, severity, actions taken, the notifications sent and their timestamps, and the review. Records are kept for at least 3 years.

8. Testing

The plan is reviewed every year, and a tabletop exercise (for example, a leaked TikTok Shop token) is run at least once a year. The plan is updated with what we learn.

1. Scope

This procedure covers the Swapt application code, its third-party dependencies (npm packages), container base images, cloud configuration and company endpoints.

2. Identifying vulnerabilities

Source	How it is used
pnpm audit	Checks every dependency against the npm advisory database; run before each release and in the monthly maintenance pass
Code review	Every change is reviewed in a pull request before release, including automated review that checks for security issues such as injection, missing authorization checks and secrets in code
Provider advisories	Security bulletins from Google Cloud, AWS, Cloudflare, Node.js and AdonisJS are followed
Monitoring	Unusual errors and failures in Sentry and the platform logs are investigated as possible exploitation
External reports	Researchers, partners and customers can report issues to andrew@swaptqr.com

3. Assessing vulnerabilities

Each finding is logged and rated using its CVSS score, adjusted for how it affects Swapt: whether the vulnerable code is reachable, whether it is exposed to the internet, and what data is at risk.

Rating	Typical CVSS	Fix target
Critical	9.0 to 10.0, or actively exploited	7 days, or immediate mitigation
High	7.0 to 8.9	14 days
Medium	4.0 to 6.9	30 days
Low	Below 4.0	90 days, or the next scheduled update

4. Fixing vulnerabilities and patching

• Fixes are made as normal pull requests: reviewed, tested by the automated test and type-check pipeline, and deployed through the standard release process.
• Dependencies are upgraded to a fixed version. Where no fix exists yet, the vulnerability is mitigated by removing or disabling the affected code path, adding input validation, or blocking it at the edge. The finding stays open until a fix is released.
• Infrastructure patching. Google Cloud patches the managed hosting platform and database, AWS and Cloudflare patch their edge services, and Swapt rebuilds its container image on each release, picking up updated base images.
• Endpoint patching. This follows the Endpoint Protection Standard: critical macOS security updates within 7 days.
• A dependency maintenance pass runs at least once a month, even when there are no open alerts. The most recent pass, on October 13, 2026, upgraded every dependency with a known vulnerability.

5. Recent security fixes

In October 2026 we tightened authorization on unauthenticated endpoints, made sign-in answers identical for unknown accounts, made webhook signature checks mandatory in every environment, stopped partner API keys from appearing in logs, and moved super-admin sign-in to Google accounts with 2-Step Verification.

6. Tracking and reporting

• Open vulnerabilities are tracked in the issue tracker until they are closed.
• Every month, the Security Owner reviews open findings against the fix targets. Overdue items are escalated and recorded in the security log.
• Exceptions (accepted risk) need the Security Owner's written approval, with a reason, compensating controls and a review date.
• A vulnerability that has been exploited is handled as an incident under the Incident Response Plan.

1. Purpose

This policy describes how Swapt collects, uses, shares, keeps and deletes personal data, including any data obtained through TikTok Shop APIs.

2. Our role

For sellers who use Swapt, Swapt acts as a service provider (processor). We process buyers' personal data only on the seller's instructions and to provide the Swapt service.

3. What we collect, and where it comes from

• From buyers who choose to opt in on a seller's Swapt page: email address, and, where the seller asks for them, name, phone number, shipping address and the order number they type in.
• From TikTok Shop APIs, with the seller's authorization: product and SKU data, and the status of an order whose number the buyer provides. We do not request or store buyer names, addresses, phone numbers or emails from TikTok Shop.
• From sellers: account and billing contact details.

4. How we use it

• Only to provide the service the seller set up: confirming an order is genuine, delivering the reward the buyer asked for, sending the emails the buyer agreed to receive, and reporting results to the seller.
• TikTok Shop data is used only for the seller who authorized it. It is never sold, never used for advertising, never combined across sellers, and never used to contact buyers.
• Every marketing email includes a one-click unsubscribe, and unsubscribes are honored right away.

5. Sharing

We share personal data only with the infrastructure providers needed to run the service (Google Cloud, Cloudflare, AWS, Temporal and Sentry), under their data processing terms, and with integrations a seller connects on purpose (for example their own Klaviyo account). We disclose data to authorities only where the law requires it.

6. Protection

Personal data is protected under the Information Security Policy: TLS for all traffic to and from Swapt, encryption at rest, least-privilege access with MFA, separation between sellers, and monitoring.

7. Data subject requests

We help sellers and TikTok Shop respond to buyers' requests to access, correct or delete their personal data. We act on a request within 30 days, or sooner if the seller or the law requires it. Requests can be sent to andrew@swaptqr.com.

8. Retention and deletion

• Personal data is kept while the seller's account is active, or for a shorter period if the seller asks.
• When a seller's contract ends, their TikTok Shop and other partner tokens are revoked and deleted immediately, and their buyers' personal data is deleted within 30 days unless the law requires us to keep it. Backups roll off within the backup retention period.

9. Breaches

Suspected breaches are handled under the Incident Response Plan. Affected sellers and TikTok Shop are notified without undue delay, and within 72 hours of confirming a breach that involves their data.

10. Training and review

Everyone with access to personal data is briefed on this policy when they join and once a year. The policy is reviewed at least once a year.