ProfitWire Information Security Policy

1. Document Control

How to read this policy:

• "Current control" describes a control that was in place and verified when this policy was written.
• "Policy requirement" is a responsibility ProfitWire commits to. Where a requirement isn't fully met yet, it is tracked internally under Section 16 and is not presented as operating.

2. Purpose

To protect customer information, business information and marketplace credentials, and to keep ProfitWire's services confidential, accurate and available.

3. Scope

This policy covers:

• ProfitWire's web application, plus its mobile and desktop versions;
• hosting and data infrastructure;
• third-party integrations, including eBay, Stripe, Google Play and, once enabled, TikTok Shop;
• administrative access;
• everyone with access to ProfitWire systems;
• all customer data processed by ProfitWire.

4. Governance and Responsibilities

ProfitWire is a small company. It has no separate security department or compliance officer.

ProfitWire Management is responsible for:

• security decisions;
• approving access;
• directing incident response;
• accepting or fixing risks;
• reviewing this policy.

Everyone with access to ProfitWire systems must follow this policy and report suspected security incidents to Management promptly.

5. Information Classification

• Public: marketing content and published policies.
• Internal: business metrics, runbooks, architecture and operating procedures. Not for publication.
• Confidential: customer account data, inventory, sales, purchases, expenses and financial reports. Available only to the owning customer and to authorized administrators for support or operations.
• Restricted: passwords, session tokens, marketplace tokens, API keys, signing keys and service credentials. Never displayed, logged, sent to browsers or stored in source code.

6. Access Control

• Current control: database access rules on every application table limit customer records to their owner.
• Current control: privileged actions are authorized on the server against a server-held role record. Roles supplied by a browser are never trusted.
• Current control: browsers cannot read the records that hold credentials.
• Policy requirement: access is granted only as needed (least privilege) and approved by Management.
• Policy requirement: administrative access is removed promptly when no longer needed, and reviewed at least annually.

7. Authentication and Credential Protection

• Current control: customers sign in through a managed authentication provider, which hashes passwords.
• Current control: sign-in sessions are issued by our authentication provider and held in the browser's local storage. Sessions are ended on sign-out and account deletion.
• Current control: email ownership must be verified before connecting a marketplace or starting paid checkout.
• Current control: server secrets are kept in the platform's secret store, never in source code.
• Current control: marketplace tokens are encrypted by ProfitWire before storage and never returned to browsers.
• Policy requirement: credentials are rotated following a written internal procedure, and each rotation is recorded.
• Policy requirement: administrator accounts use strong, unique credentials and multi-factor authentication wherever the provider supports it.

8. Customer Data Protection

• Current control: HTTPS is enforced for all traffic, with HTTPS-only browser instructions and restrictive browser security headers.
• Current control: encryption at rest is provided by the managed database and storage provider (a provider control).
• Current control: customer accounts are kept separate by database access rules and server-side authorization.
• Current control: integration credentials are exchanged and held only on the server.
• Policy requirement: customer data is used only to provide and support the service, as described in the Privacy Policy.

9. Application Security

• Current control: automated type checks, tests, code-quality checks and a production build run on changes to the main code line. Dependency versions are locked.
• Policy requirement: the owner explicitly reviews changes to sign-in, permissions, billing or financial calculations before release.
• Policy requirement: known dependency vulnerabilities are reviewed regularly and fixed in order of severity.
• Policy requirement: production releases can be rolled back following a written procedure.

10. Logging and Monitoring

• Current control: application errors are recorded through error monitoring and an internal error log.
• Current control: scheduled health checks confirm sign-in and background-job availability.
• Current control: background-job endpoints reject callers other than ProfitWire's scheduler.
• Policy requirement: security events (for example, bursts of failed sign-ins, repeated authorization failures and abnormal request volume) are to be monitored and alerted on. This is not yet implemented, and this policy does not claim it is.

11. Incident Response

ProfitWire handles incidents under written internal procedures covering:

• Identification: recognizing and recording a suspected incident.
• Containment: limiting harm, including revoking or rotating affected credentials.
• Investigation: determining which accounts and data were affected.
• Recovery: returning to normal, verified operation.
• Documentation: recording the timeline, evidence and decisions.
• Notification: notifying affected customers, authorities or partners when law or contract requires it. Management decides on notification.

12. Backup and Recovery

• Current control: database backups are provided by the managed database provider.
• Current control: ProfitWire keeps a written restore procedure.
• Policy requirement: confirm which recovery points are available, and complete a documented test restore. Until then, ProfitWire makes no commitment to a recovery time or recovery point.

13. Data Retention and Deletion

• Policy requirement: collect and keep only the data needed to provide the service and meet legal obligations. Retention periods are those stated in the Privacy Policy.
• Current control: customers can request deletion through account settings, the account-deletion page or the Data Requests page. Requests are handled under a written internal procedure.
• Current control: account deletion ends the customer's sign-in sessions and erases stored marketplace access tokens.
• Current control: customers can disconnect eBay on the web or in the mobile app. Disconnecting stops future syncing and deletes the eBay access credentials stored by ProfitWire, while keeping the customer's inventory, purchases, sales and financial history. ProfitWire does not revoke authorization at eBay; customers can do so in their eBay account settings.
• Policy requirement: before any new marketplace integration is enabled for customers, ProfitWire confirms that its stored connections are erased on disconnect and during account deletion, including during the deletion grace period.

14. Third-Party Service Providers

ProfitWire relies on these providers for the controls listed:

• Managed database and authentication platform: database, sign-in, file storage, backups and encryption at rest.
• Cloudflare: application hosting and network delivery, including its own network protections.
• Stripe: card payment processing. ProfitWire never holds full card numbers.
• Google: Google sign-in and Google Play subscription billing.
• eBay: marketplace data, under the seller's authorization.
• TikTok Shop (once enabled): shop data, under the seller's authorization.

ProfitWire remains responsible for:

• application authorization and database access rules;
• how credentials are handled and how tokens are encrypted;
• which integration permissions it requests;
• how integration data is used, kept and deleted.

Policy requirement: providers are reviewed when added or when their role changes significantly.

15. Security Reviews

Policy requirement: Management reviews this policy and the internal corrective-action register (Section 16) at least annually, and after any significant change to infrastructure, integrations or sign-in.

16. Exceptions and Corrective Actions

• Known security gaps are recorded in an internal register with a risk level, an owner and a target date.
• Gaps are prioritized by customer impact.
• Fixes are approved by Management before release.
• Exceptions to this policy require written Management approval and an expiry date.
• The register is internal and is not published.

17. Policy Approval

• Approved by: Ross Johnstone
• Title: Owner, ProfitWire LLC
• Date approved: October 12, 2026
• Effective date: October 12, 2026
• Approval method: Written authorization by the owner through ProfitWire's change-approval workflow (no handwritten or electronic signature).

Related: Security at ProfitWire · Privacy Policy · Data Requests