Written Information Security Plan (WISP)

Andivano LLC — Taxller


Effective date	2026-09-13
Version	1.8
Approved by	Managing Member, Andivano LLC
Security / support contact	info@taxller.com

1. Purpose & Scope

This Written Information Security Plan ("WISP") describes the administrative, technical, and physical safeguards that Andivano LLC, a Florida single-member LLC operating the product Taxller (https://taxller.com), applies to protect the information it collects, processes, and stores.

Taxller is a cloud bookkeeping and tax-compliance SaaS built for US-based Amazon sellers. Taxller has been live in early access since August 13, 2026, and production holds real customer account data and seller-uploaded documents.

On September 8, 2026 the production environment was migrated off Amazon Web Services onto a dedicated single-tenant Linux server operated by Andivano LLC (the "production server", located in the United States). The application and its PostgreSQL database now run on that server behind a TLS-terminating reverse proxy; they no longer run on AWS container or managed-database services. Two AWS services remain in use and remain in scope: encrypted S3 object storage for customer documents and assistant attachments, and Amazon Bedrock (US regions only) for the product's AI assistant.

Paid subscriptions have been available since August 22, 2026. Billing is processed by Stripe; card data is handled entirely inside Stripe's PCI DSS-compliant environment and never reaches Taxller systems (Section 12).

This WISP describes (a) the security controls operating in production today, and (b) the specific, dated commitments Andivano LLC is making for controls that mature at defined trigger points, rather than claiming those controls are already operating.

This WISP applies to:

The Taxller production server: the application, its PostgreSQL database, the reverse proxy, the release mechanism, and the backup chain.
The AWS services the product still depends on — the S3 document store and Amazon Bedrock — held in an AWS account dedicated to Taxller (us-east-1).
The Taxller product repository (source code, CI/CD, dependency management).
The Taxller marketing site (taxller.com, hosted on Hostinger, static export — a separate, non-application surface with no access to product data).
Andivano LLC's Amazon Selling Partner API (SP-API) presence, which is deliberately split into two separate Solution Provider Portal accounts so that the product and the company's own trading never share one review surface, one set of credentials, or one point of failure:
- The Taxller application (the subject of this WISP). Andivano LLC is registering a second Solution Provider Portal account, held by the same legal entity under its own login, as a Public developer so that other selling partners can authorize this application. That account requests exactly four non-restricted roles — Finance and Accounting, Inventory and Order Tracking, Amazon Fulfillment, and Selling Partner Insights — to be exercised on behalf of Taxller's seller customers, each under that seller's own OAuth authorization. Until the registration is approved, no third-party seller has authorized the application.
- A pre-existing private integration, predating the Taxller application, on Andivano LLC's original developer profile. That profile stays Private and unchanged. It holds seven approved non-restricted roles — the four above plus Product Listing, Pricing, and Brand Analytics — used exclusively for Andivano LLC's own Amazon seller account under self-authorization, and never exercised on behalf of a third-party selling partner. It is out of scope for the Taxller application except where this plan says otherwise (Section 7a).
Every role held or requested in either account is non-restricted; no restricted role, and no role that grants access to Amazon buyer personal data, is held or requested anywhere.
The internal automation environment behind Andivano LLC's private SP-API integration described above — a dedicated, hardened Linux host, documented in Section 7a.

Where this document states an infrastructure control in the present tense, that statement is attested by dated evidence kept alongside this document: the output of the AWS baseline verification script (infra/aws-baseline/verify.sh, or its read-only boto3 equivalent infra/aws-baseline/verify.py, which checks the same controls from a workstation) for the AWS services in scope, and the production server's own acceptance record — firewall rules, externally reachable ports, service inventory, and a verified backup restore — captured at the September 8, 2026 migration and re-captured whenever that host's configuration changes. The plan is not submitted to any third party before that evidence is refreshed.

This document is published in the product repository and mirrored on the public /security page. It is reviewed at least annually per Section 14, and companion to the separate Incident Response Runbook (same repository, same effective date), which governs operational incident-handling procedures.

2. Roles & Responsibilities

Andivano LLC is a single-member LLC. As of this document's effective date there are no employees or contractors with access to Taxller infrastructure or data.

Role	Assigned to	Responsibilities
Security Officer / Data Protection Owner	Managing Member, Andivano LLC	Owns this WISP and the Incident Response Runbook; approves all changes to security policy; sole holder of AWS root credentials; final authority on access grants.
Incident Commander	Managing Member, Andivano LLC	Leads incident detection, containment, and notification per Section 13 and the Incident Response Runbook, until a dedicated hire assumes the role.
Administrator (AWS, GitHub, SP-API app)	Managing Member, Andivano LLC	Day-to-day administration of the production server, the dedicated AWS account, the product repository, and the SP-API developer application.

Commitment — trigger: first additional hire or contractor with system access. Before any person other than the Managing Member is granted access to Taxller infrastructure, source code, or seller data, that individual will be assigned a named account (no shared/generic logins), scoped to least privilege for their function, and added to the quarterly access review described in Section 4.

3. Data Classification

Taxller's zero-buyer-PII design is a direct consequence of the SP-API roles it requests: Finance and Accounting, Inventory and Order Tracking, Amazon Fulfillment, and Selling Partner Insights are all classified by Amazon as non-restricted — none of them return Amazon buyer names, addresses, emails, or other buyer-identifying data. Taxller does not request, and by its application scope cannot receive, Amazon buyer PII.

Category	Examples	Classification	Source
Amazon buyer PII	Buyer name, address, email, phone	Not collected	Excluded by design — none of the non-restricted SP-API roles held or requested by Andivano LLC (the four requested by the Taxller application's account and the seven approved on the private profile, Section 1) return buyer PII
Amazon seller operational data	Financial/settlement reports, order and inventory data, fulfillment data, Selling Partner Insights	Confidential	Retrieved from SP-API under the seller's own OAuth authorization
Taxller customer account data	Seller's business name, contact email, tax ID (EIN/SSN where applicable for tax-compliance features), billing/subscription status	Confidential / Restricted (tax ID)	Collected directly from the Taxller customer at signup
Payment & billing data	Subscription and wallet status, invoices, payment-method metadata (card brand and last four digits)	Confidential	Created by Stripe. Card numbers, CVC, and full payment credentials never transit or rest on Taxller systems (Section 12)
Credentials & secrets	LWA client ID/secret, LWA refresh tokens, AWS/IAM credentials, API keys	Restricted	Issued by Amazon, AWS, and Stripe
Public content	Marketing site copy, blog, public documentation (incl. this WISP)	Public	Authored by Andivano LLC

The Amazon seller's own operational data (financial, inventory, order, and fulfillment data returned by SP-API) and the Taxller customer's own account/tax data are treated as Confidential and protected under the same controls described in Sections 4–7, even though neither category constitutes Amazon buyer PII.

4. Access Control

Production server. Administrative access is by SSH public key only — password authentication is disabled at the SSH daemon — and the SSH service is reachable only over Andivano LLC's private overlay network, never from the public internet. The host firewall's default inbound policy is deny. Only named operating-system accounts may log in (AllowUsers), MaxAuthTries is 3, and a failed-authentication jail bans a source address for one hour. The application runs under its own unprivileged account, and the configuration file holding its secrets is mode 600, owned by that account.
Dedicated AWS account. The AWS services Taxller still uses — the S3 document store and Amazon Bedrock — live in an AWS account created solely for Taxller, separate from any Amazon seller account, region us-east-1. The production server reaches them through a dedicated IAM user scoped to that account's own object prefixes and to the two pinned Bedrock models, and to nothing else.
Root user: MFA-enabled; no root access keys exist or will be created; root is not used for day-to-day administration.
IAM: named, individual users/roles — no shared or generic logins. All administrative and console access requires MFA using an approved factor (hardware-backed passkey/FIDO2, TOTP authenticator app). A single named administrative IAM user exists for standing up and operating the account baseline; it will be decomposed into narrower, function-scoped roles (e.g., deploy, read-only audit) as additional infrastructure and any additional personnel are introduced.
Password policy: IAM account password policy requires a minimum of 14 characters with mixed-case letters, numbers, and special characters; passwords expire after 90 days and the last 24 cannot be reused — exceeding Amazon's 12-character minimum and 365-day expiration baseline.
Taxller account passwords (the selling partners who sign in to the product): a minimum of 12 characters with uppercase, lowercase, digit and special-character classes all required; candidates are rejected if they appear in a known-breach corpus (k-anonymity lookup, the password never leaves the server); the last 10 passwords cannot be reused; a password older than 365 days forces a change at the next sign-in. The minimum was raised from 8 to 12 on 2026-09-12 to meet Amazon's baseline, and the running product, this plan and the developer-profile questionnaire now state the same policy.
Multi-factor authentication for Taxller accounts. TOTP multi-factor authentication is optional for general dashboard access (an owner decision of 2026-08-16) and is enforced where the risk sits: an account that has enrolled an authenticator must verify it on every new session; a password sign-in on an account without one is confirmed by a single-use code e-mailed to the verified address; and starting an Amazon authorization — the only path by which SP-API data reaches Taxller — is refused unless the user has an enrolled authenticator verified within the preceding five minutes, and the authorization must then complete within ten minutes. The same fresh verification is required to connect any marketplace channel, invite a member, or disable multi-factor authentication.
Account lockout — in place. Taxller's authentication layer locks an account for one hour after 10 consecutive failed sign-in attempts, meeting Amazon's "10 or fewer" baseline. The control escalates before it locks: a CAPTCHA challenge is required from the second consecutive failure and an increasing server-side delay from the third; the failure counter decays after 15 minutes without a further attempt; and the account holder can unlock immediately through a single-use emailed link. The counter lives in the application's database, so the limit is per account and survives a restart. This fulfils the commitment made in version 1.0 of this plan, whose trigger — the first customer-facing login — was reached on August 13, 2026.
Access reviews. Access is currently limited to one individual (the Managing Member); a quarterly review of all personnel and service-account access is instituted as of this document's effective date, with the first review due no later than 2026-11-04 and every quarter thereafter, regardless of headcount.
Termination. Access for any departing employee, contractor, or service integration is revoked within 24 hours of termination or end of engagement.

5. Encryption

In transit. All data in transit to and from Taxller systems — including calls to the Amazon SP-API — uses TLS 1.2 or higher; weaker protocols are not enabled. The production server terminates TLS at its reverse proxy with a publicly trusted certificate that renews automatically; plain HTTP serves only the redirect to HTTPS and certificate validation. AWS-managed endpoints in the dedicated account (S3, KMS, CloudTrail, Bedrock) enforce TLS 1.2+ by default. Administrative access to the production server travels over SSH-2 inside an encrypted private overlay network.

At rest.

Customer documents and assistant attachments are stored in Amazon S3 with default server-side encryption (AES-256), object versioning, and account-level Block Public Access — no bucket in the account can be made public. The production server's IAM user may write only to its own object prefixes.
Database backups are taken daily, kept 14 days on the server, and copied to that same encrypted, versioned S3 account. The server's key is write-only to the backup prefix, so a compromised server cannot read back or destroy earlier copies.
Amazon SP-API refresh tokens belonging to a selling partner are encrypted at the application layer before they reach the database, and only the ciphertext is stored; the key lives outside the database, in the server's mode-600 configuration file (Section 6). A database copy — including a backup copy in S3 — therefore yields no usable seller token. The same mechanism protects stored multi-factor secrets.
A customer-managed KMS key (CMK) with annual automatic rotation encrypts the AWS account's CloudTrail log bucket.
The data at rest on the production server is held on an encrypted volume. Since September 11, 2026 the PostgreSQL data directory, the mode-600 secrets file (Section 6) and the local backup copies live inside a LUKS2 container (AES-XTS-512, Argon2id) opened as a device-mapper volume and mounted at /srv/secure; their former paths are bind-mounted onto it, so no configuration path changed. Swap is a separate device-mapper volume keyed randomly at every boot. The passphrase is not stored on the host and cannot be recovered from it — after a reboot the volume is opened from an operator workstation that holds it, and the database and application units refuse to start until it is mounted.
The operating-system volume itself is not encrypted. It carries no seller data, no secrets and no backups — all three live inside the container above. The compensating controls remain in force: the database listens on the loopback interface only and no database port is reachable from any network (Section 7); every copy of the data that leaves the host — documents and backups — is encrypted (above); the highest-sensitivity values inside the database are additionally encrypted at the application layer (above); and the data held contains no Amazon buyer PII (Section 3).
Verified, not asserted. On September 12, 2026 that day's backup was restored into a scratch database on the production host: 56 tables, zero pg_restore warnings, and row counts identical to production on every table checked. The scratch database and the working copies were destroyed immediately after the check. The commands and their output are kept as evidence alongside this document (evidence/2026-09-12-encrypted-volume-and-restore-test.md). This closes the commitment made in version 1.4 to move the database onto encrypted storage and verify the move by a restore test.

AES-256, used for every encrypted store above, meets and exceeds Amazon's data-encryption standard (minimum AES-128, AES-256 preferred, or RSA-2048+).

6. Credential & Secrets Management

Where production secrets live. The production environment's secrets — the SP-API application credentials, Stripe keys, the database connection string, the AWS access key for the S3/Bedrock user, and the application's own encryption secret — are held in a single configuration file on the production server (the internal-integration environment is described in Section 7a), mode 600, owned by the unprivileged account that runs the service, and stored on the encrypted volume described in Section 5. That file sits outside any repository, outside the release artifact, and outside the database backup stream; its values are never embedded in client-side code, committed, or logged in plaintext.
Per-seller LWA refresh tokens are never written in plaintext. Each is encrypted at the application layer under the key held in that configuration file, and only the ciphertext is stored — in a per-connection row scoped to the authorizing customer, so the store itself offers no cross-tenant exposure.
Rotation. SP-API application credentials and long-lived tokens are rotated at least annually, or immediately upon suspected compromise. The long-lived AWS access key held on the production server is rotated at least every six months — a compensating measure recorded at the September 8, 2026 migration for the automatically rotated container role the application used before it.
AWS root: no access keys exist for the root user (see Section 4). IAM user credentials are never shared between individuals.
Repository secrets (CI/CD tokens, deployment credentials) are stored in GitHub's encrypted repository secrets store, scoped to the minimum workflows that require them, and never printed to CI logs.

7. Network Security

Isolation. Production runs on a single-tenant server dedicated exclusively to Taxller: it hosts no other product, and it is separate from the internal automation environment of Section 7a and from any Amazon seller account.
Host firewall and exposed surface. The firewall's default inbound policy is deny. Exactly three inbound ports are reachable from the internet: TCP/80 and TCP/443 (the reverse proxy — port 80 serves only the HTTPS redirect and certificate validation), and the overlay network's UDP transport port. The PostgreSQL database listens on loopback only and is reachable from no network; the application process likewise listens on loopback and is reached only through the reverse proxy; SSH is reachable only over the private overlay interface. A guard rule prevents container runtimes from publishing ports around the firewall. This posture was verified by an external port scan at the September 8, 2026 migration and is re-verified whenever the host's service configuration changes.
Brute-force protection at the edge. Failed-authentication jails read the SSH and web-server logs and ban a source address for one hour (SSH: 4 failed attempts; web sign-in: 12 failed attempts within five minutes). Andivano LLC states plainly that this replaced the managed web application firewall that fronted the application before the migration and is a weaker control at the network edge; the primary defences against credential attack are therefore the per-account lockout, CAPTCHA escalation and server-side delay of Section 4, and step-up re-authentication on sensitive actions — all of which act inside the application regardless of source address.
Amazon GuardDuty remains enabled account-wide in the Taxller AWS account, providing managed threat detection across the account that holds the document store and Bedrock access, alongside S3 Block Public Access. It no longer observes the application tier, which left AWS on September 8, 2026.
Availability and integrity monitoring. A watchdog on the production server checks application health every five minutes and, on failure, restarts the service and emails the Managing Member. Releases are installed transactionally and roll back automatically if the new version does not answer its health check.
Marketing site separation. taxller.com is a static export hosted on Hostinger, entirely separate from the product's AWS infrastructure and from any seller or customer data — it has no code path that touches product data. A security.txt file is published at /.well-known/security.txt with the security contact (info@taxller.com).
Endpoint protection — commitment, trigger: first additional device/personnel with system access. The Managing Member's administrative workstation runs OS-native anti-malware protection with automatic signature updates. Before any additional personnel are granted device-level access to systems that handle seller or customer data, Andivano LLC will adopt centrally managed endpoint protection with monthly-or-better update enforcement and controls that prevent end-user disablement.

7a. Internal Integration Environment

Andivano LLC's pre-existing private SP-API integration (Section 1) — used exclusively for its own Amazon seller account and never on behalf of a third-party selling partner — runs on infrastructure separate from the Taxller product's dedicated AWS account described elsewhere in this document. This section documents that environment's safeguards.

Hardened Linux host. A dedicated Linux VPS, administered solely by the Managing Member.
Key-only SSH. Authentication is by SSH key only; password authentication is disabled at the SSH daemon level.
Minimal public attack surface. The host exposes exactly one public TCP listener — TCP/22 (SSH) — and exactly one wildcard-bound UDP socket, the overlay network's own WireGuard NAT-traversal port, which carries no integration service. Every service the integration runs is bound to loopback (127.0.0.1) or to the private overlay-network (tailnet) interface, never to a public address. The host's mDNS service discovery, which previously also held wildcard UDP sockets, was disabled on 2026-08-05 as unnecessary to this host's function. This posture, including the attribution of each remaining socket to its owning process, is verified by dated port-scan evidence kept alongside this document — captured before and after that change — and re-run whenever the host's service configuration changes.
Secrets handling. Credentials for this integration (SP-API application credentials, refresh tokens, and any other secrets) are held in a permission-restricted environment file, readable only by the operating-system account that runs the integration, and are never committed to any repository. Credentials in the environment file are rotated at least annually, or immediately upon suspected compromise.
No buyer PII. Consistent with Section 3, this integration requests and stores no Amazon buyer personal data.
Logging. systemd journals and application logs capture operational activity for this host.
Commitment, trigger: 2026-09-30. Raw SP-API report archives currently held on this host's local disk will be migrated to Amazon S3 with SSE-KMS encryption at rest, matching the encryption standard already applied in the Taxller AWS account (Section 5).

8. Logging & Monitoring

Log source	Retention	Notes
Production server — systemd journal (application, service, and OS events)	≥ 12 months	Entries are kept for up to one year (`MaxRetentionSec=1year`) under a 4 GB size cap; disk usage is checked at the bi-weekly log review so that the cap never shortens retention below the 12-month minimum in Amazon's SP-API logging and monitoring guidance.
Production server — reverse-proxy access log	≥ 12 months	A separate JSON log file written by the reverse proxy, rotated at 50 MiB and kept for up to 366 days (`roll_keep_for`) under a 40-file cap. At the measured volume (under 1 MB a day in September 2026) the cap holds several years, so the 366-day limit is the one that applies; volume is re-checked at the bi-weekly log review. Records request metadata, not request bodies.
Application security events, in PostgreSQL (sign-in attempts and lockouts, session creation and revocation, security e-mails sent, account activity feed)	≥ 12 months	Included in the daily encrypted backup, so the record survives replacement of the host.
SP-API data-access journal — commitment, trigger: first selling-partner authorization	≥ 12 months	Which selling partner, which data window, which outcome, for every synchronisation run; specified together with the seller-connection feature and retained at least twelve months.
AWS CloudTrail (all-regions trail) → dedicated S3 bucket, SSE-KMS	≥ 365 days (bucket lifecycle policy)	Covers the AWS account that holds the document store and Bedrock access.

Alerting. On the production server, the health watchdog emails the Managing Member when the service fails or is restarted, and the release mechanism reports any failed or automatically rolled-back deployment. In the AWS account, an EventBridge rule watches for root-account sign-in and unauthorized/denied API calls and publishes to an SNS topic that emails info@taxller.com; that email subscription is confirmed and end-to-end delivery has been tested.
Review cadence. The Managing Member reviews the production server's authentication and error logs, and CloudTrail and GuardDuty findings, at least bi-weekly and immediately upon any automated alert — meeting Amazon's minimum bi-weekly review cadence for organizations without a dedicated SIEM.
Log content. Logs are not designed to capture buyer PII (moot today, since Taxller collects none) and application logging excludes customer PII and secrets by default, consistent with Amazon's requirement that logs exclude PII unless legally required. Model-invocation logging is disabled in the AI assistant's Bedrock configuration, so customer conversations are not retained by that service.
Budget anomaly alerting. An AWS Budgets alarm notifies info@taxller.com if account spend crosses a defined monthly threshold, acting as an additional signal for anomalous or unauthorized resource use.

Note on a documentation discrepancy: Amazon's SP-API Security and Compliance Overview index page states a general "90-day minimum" log retention figure, while the dedicated Logging and Monitoring guidance page specifies "at least 12 months." Andivano LLC treats the dedicated page's 12-month figure as authoritative and has sized production-server journal retention, database-resident security records, and CloudTrail retention to satisfy the stricter figure.

9. Vulnerability Management

Amazon's 30-day scan / annual pentest / 7-day-critical remediation requirements are scoped under the Data Protection Policy's PII-Additional controls (§2.7). Because Taxller's SP-API scope excludes buyer PII by design (Section 3), these controls are not strictly mandated for the current application. Andivano LLC nonetheless applies the following, in recognition that the product still handles sensitive business and tax data:

Already in place: Dependabot dependency-vulnerability scanning runs continuously against the product repository; CI quality gates (lint, typecheck, tests) run on every pull request, so code-level scanning precedes every release; and the production server applies operating-system security updates automatically through unattended upgrades.
Scheduled dependency scanning — in place from this version's effective date. A scheduled job in the product repository scans the application's full resolved dependency tree against public vulnerability databases at least every 30 days, and again on every change to the lockfile. Findings are triaged by the Managing Member on the same cadence as Dependabot alerts.
Commitment — trigger: before Taxller ingests SP-API data belonging to any selling partner other than Andivano LLC. Andivano LLC will add an authenticated infrastructure vulnerability scan of the production host on the same 30-day cadence, and commission a third-party penetration test of the application, repeated at least annually thereafter. Critical-risk findings are remediated within 7 days of discovery and high-risk findings within 30 days, matching Amazon's stated thresholds.

10. Secure Development

CI/CD gates. Every pull request to the product repository runs lint, typecheck, and test jobs; merges require these checks to pass.
Branch protection. The default branch is protected — changes land only via pull request; direct pushes are disabled.
Dependency management. Dependabot is configured on the repository to open update PRs for vulnerable or outdated dependencies, which then pass through the same CI gates before merge.
Secrets hygiene. No credentials, API keys, or tokens are committed to the repository; local secret files are git-ignored, and CI/deployment secrets live in GitHub's encrypted secrets store or in the production server's mode-600 configuration file (Section 6).

11. Data Retention & Deletion

Taxller production holds customer account data, questionnaire answers, and seller-uploaded documents (early access, since August 2026). Customer-facing retention and deletion commitments are stated in the Privacy Policy (taxller.com/legal/privacy) and honored by manual request handling. The following retention posture applies to infrastructure and operational data:

Infrastructure and application logs: per Section 8 — production-server journals and database-resident security records for at least 12 months, AWS CloudTrail for at least 365 days.
SP-API seller data: once ingestion begins, seller financial/inventory/order/fulfillment data is retained only as long as necessary to provide the service to that seller or as required by applicable tax-recordkeeping law, whichever is longer.
Account closure / SP-API de-authorization: upon a seller disconnecting their Amazon account or closing their Taxller account, associated seller data and credentials (including the stored, encrypted refresh token) are deleted within 30 days, absent a legal requirement to retain longer.
Published customer-facing policy. The retention and deletion policy is published in Taxller's Terms of Service and Privacy Policy (taxller.com/legal), which state the 30-day rule for SP-API data following a deletion request, de-authorization, or account closure. This fulfils the commitment made in version 1.0 of this plan, whose trigger — first customer onboarding — was reached in August 2026.

12. Subprocessors

Subprocessor	Purpose	Data involved
Amazon Web Services, Inc.	Encrypted S3 object storage for customer documents and assistant attachments; Amazon Bedrock (US regions only) for the AI assistant; CloudTrail and GuardDuty for that account	Customer documents and attachments; the content of assistant conversations at inference time — model-invocation logging is disabled and the data is not used to train models
ExtraVM LLC	Hosting of the production server (United States)	Hosting of the application and its database. The provider is not granted administrative access to the application, its database, or its secrets
Stripe, Inc.	Subscription billing and payment processing — live since August 22, 2026	Payment/billing data; card data is handled entirely within Stripe's PCI DSS-compliant environment and never touches Taxller infrastructure
Resend	Transactional email delivery (security notifications, invitations, billing receipts)	Recipient address and message content of transactional email; no seller operational data
Cloudflare, Inc.	CAPTCHA challenge (Turnstile) on authentication surfaces	Challenge metadata only; no account, customer, or seller data
Google LLC	Optional "Sign in with Google" federated authentication, for customers who choose it	Sign-in identity (verified email address) only
GitHub, Inc.	Source repository, continuous integration, and release-artifact distribution	Source code and build artifacts; no customer or seller data
Hostinger	Static hosting for the public marketing site (taxller.com)	Public marketing content only — no product, seller, or customer data
Have I Been Pwned (HIBP)	Password breach screening at registration and on every password change or reset	The first five characters of the password's SHA-1 hash (k-anonymity range query); never the password, the account or any seller data
Internal accounting server provider (United States)	Virtual private server on which Andivano LLC keeps its own books	Copies of the invoice and credit-note PDFs Taxller issues to its customers and the related billing register; no seller operational data

Customer and seller data at rest — documents, the production database, and its backups — resides in the United States, and the AI assistant's inference profile is pinned to US regions. Subprocessors that carry no customer or seller data (marketing-site hosting, CAPTCHA) are listed for completeness.

The Amazon SP-API itself is the data source under each seller's own authorization, not a subprocessor of Andivano LLC.

13. Incident Response

Operational incident-handling procedures (detection, containment, eradication, recovery, and communication) are defined in the companion Incident Response Runbook, committed to this same repository, version 1.3, effective 2026-09-13.

Amazon notification. In the event of a security incident affecting SP-API data, credentials, or application access, Andivano LLC notifies Amazon at security@amazon.com within 24 hours of detection, per the Data Protection Policy's Risk Management and Incident Response Plan requirement.
Escalation. As a single-member LLC, the Managing Member is the sole incident commander and point of contact; there is no additional internal escalation chain today. This will be expanded as additional personnel join.
Customer/regulatory notification. Taxller has customers in early access, so this is an active obligation rather than a future one. On a confirmed breach of customer or seller data, Andivano LLC notifies each affected customer without undue delay, at the email address on their account, stating what happened, which categories of data were involved, and what the customer should do; and makes any regulatory notification required by applicable United States state breach-notification law. The operational procedure is carried in the Incident Response Runbook.
Contact. info@taxller.com is the published security contact (also listed in /.well-known/security.txt on the marketing site).

14. Policy Review

This WISP is reviewed at least annually, and additionally whenever there is a material change to Taxller's infrastructure, roles/responsibilities, subprocessors, or applicable Amazon/legal requirements. The next scheduled review is due no later than 2027-08-04.

An annual risk assessment of Taxller's systems, data flows, and vendors/subprocessors (Section 12) is conducted alongside this review and its outcome is approved by the Managing Member — consistent with the Data Protection Policy's risk-management requirement (§1.6) and its vendor risk-assessment expectation (§2.8). The first assessment is due together with the first scheduled review, no later than 2027-08-04.

Version History

Version	Date	Approved by	Summary
1.0	2026-08-04	Managing Member, Andivano LLC	Initial WISP, aligned to the AWS security baseline established in Taxller's dedicated AWS account and to Amazon's SP-API Data Protection Policy guidance.
1.1	2026-08-04	Managing Member, Andivano LLC	Scope (Section 1) rewritten to cover all seven roles approved on Andivano LLC's SP-API developer profile — the four Taxller public-application roles plus three additional roles (Product Listing, Pricing, Brand Analytics) used only for Andivano LLC's own seller account under a pre-existing private integration; added Section 7a documenting that integration's hardened-host environment; updated Section 3's PII-exclusion note to the seven-role total; published this document on the public `/security` page.
1.2	2026-08-05	Managing Member, Andivano LLC	Section 7a's attack-surface statement made precise: the host exposes exactly one public TCP listener (SSH), and the three wildcard-bound UDP sockets — the overlay network's WireGuard NAT-traversal port and the host desktop's mDNS discovery, neither of which carries an integration service — are now named in the text rather than only in the port-scan evidence file it references. No control changed; the previous wording said "one public network listener" without qualifying TCP, which a reader comparing it against a live `ss` capture would read as inaccurate.
1.3	2026-08-05	Managing Member, Andivano LLC	Section 7a updated after remediation: the host's mDNS service discovery (avahi) was disabled as unnecessary to this host's function, leaving exactly one public TCP listener (SSH) and one wildcard-bound UDP socket (the overlay network's WireGuard transport). Port-scan evidence for 2026-08-05 now contains both the before and after captures.
1.4	2026-09-11	Managing Member, Andivano LLC	Brought the plan to the September 2026 state of the product. Production was migrated off AWS onto a dedicated single-tenant Linux server on 2026-09-08, so Sections 1, 4, 5, 6, 7, 8 and 12 were rewritten to describe the server (firewall posture, loopback-only database, key-only SSH over a private overlay, failed-authentication jails, transactional releases with automatic rollback, daily encrypted backups) and to scope the remaining AWS footprint to the S3 document store and Amazon Bedrock. Three statements that had become untrue were corrected rather than left standing: paid subscriptions are live (since 2026-08-22) and payment data is processed by Stripe; the account-lockout control promised in 1.0 is implemented and is now described as delivered; and Taxller has customers, so customer and regulatory breach notification is an active obligation. Newly stated plainly: the production server's own disk volume is not encrypted at rest, and the managed web application firewall was not replaced in kind — both carry compensating controls and a dated commitment. Added scheduled 30-day dependency scanning; added the payment-data class and the full subprocessor list (hosting provider, Bedrock, Resend, Cloudflare Turnstile, Google sign-in, GitHub).
1.5	2026-09-12	Managing Member, Andivano LLC	Corrected Section 5 to the state of the host after September 11, 2026. Version 1.4 stated plainly that the production server's volume was not encrypted at rest and committed to moving the database onto encrypted storage before ingesting another selling partner's data; that move was carried out on 2026-09-11 and the plan had not caught up. The database, the mode-600 secrets file and the local backups now sit inside a LUKS2 container (AES-XTS-512, Argon2id) whose passphrase is not held on the host, with swap on a separately keyed volume; the operating-system volume remains unencrypted and is described as carrying none of that data. The commitment is closed by a restore test run on 2026-09-12 — 56 tables, zero warnings, row counts identical to production — whose commands and output are kept in `evidence/2026-09-12-encrypted-volume-and-restore-test.md`.
1.6	2026-09-12	Managing Member, Andivano LLC	Section 4 now states the password policy for Taxller accounts themselves, not only for administrative access: 12-character minimum (raised from 8 the same day, to meet Amazon's baseline), four character classes, breached-password rejection, 10-password history, 365-day maximum age enforced at sign-in, and mandatory TOTP MFA. Added so that the plan, the developer-profile questionnaire and the running product describe one policy.
1.7	2026-09-13	Managing Member, Andivano LLC	Corrected Section 1 to the SP-API structure actually being built. Version 1.6 said Andivano LLC was applying to move its single developer profile to Public; that plan was dropped on 2026-09-12 in favour of a second Solution Provider Portal account held by the same legal entity, so that a review of the public application can never reach the seven approved roles the company's own trading depends on. The original profile stays Private and unchanged, and the new account requests only the four roles Taxller uses. Also recorded the read-only boto3 equivalent of the AWS baseline verification script, which produced the 2026-09-13 evidence.
1.8	2026-09-13	Managing Member, Andivano LLC	Corrected two statements that the code and the host contradicted. Section 4 said TOTP multi-factor authentication was mandatory for every Taxller account; it has been optional for general dashboard access since an owner decision of 2026-08-16 (`apps/web/lib/server/session-gates.ts`). The section now states what is enforced: verification on every new session once enrolled, an e-mailed single-use code for a password sign-in without an authenticator, and an enrolled authenticator verified within five minutes before an Amazon account can be connected. Section 8 said the reverse-proxy access log was the same journal as the systemd journal; it is a separate JSON file, rotated at 50 MiB, which on 2026-09-13 was also set to keep rotated files for up to 366 days under a 40-file cap. Evidence: `evidence/2026-09-13-log-retention-and-mfa.md`. Also brought forward facts the plan had not recorded: the IAM password policy expires passwords after 90 days and blocks reuse of the last 24; the Amazon step-up applies when an authorization starts, which must then complete within ten minutes; the journal and proxy-log retention rows now name their size caps and how those caps are checked; Section 12 lists Have I Been Pwned and the internal accounting server, which the Privacy Policy already names; Section 3 and Section 13 now match Section 1 and the runbook's current version.

Appendix A: Amazon SP-API Data Protection Policy Cross-Reference

Provided for reviewer convenience. "Applicability" reflects whether the cited control is general (applies to all SP-API developers) or scoped to the PII-Additional section of the policy — Taxller requests zero buyer PII (Section 3), so PII-Additional controls are noted as such even where Taxller elects to meet them anyway.

DPP topic	Applicability	Taxller control	Reference
Encryption in transit (≥ TLS 1.2)	General	Section 5	Guidance to address key security controls
Encryption at rest for PII (AES-128/256, RSA-2048+)	PII-Additional	Section 5 (AES-256 for documents, backups, and application-layer encryption of seller tokens; the database, the secrets file and the local backups sit on a LUKS2-encrypted volume whose key is not held on the host, verified by a restore test)	Protecting SP-API applications — data encryption
Credential/API key encryption & annual rotation	General	Section 6	Guidance to address key security controls
MFA and account lockout (≤ 10 attempts)	General	Section 4	Guidance to address key security controls
Password policy (≥ 12 chars, complexity, history, expiration)	General	Section 4 (14-char minimum for administrative access; 90-day expiry and MFA for administrative access; 12-char minimum, four classes, breach check, 10-password history and 365-day maximum age for Taxller accounts; MFA required to connect an Amazon account)	Guidance to address key security controls
Quarterly access review; 24-hour termination removal	General	Section 4	Guidance to address key security controls
Network protection (firewalls, segmentation, IDS/IPS, AV)	General	Section 7	Guidance for network protection in SP-API
Log retention ≥ 12 months; bi-weekly/SIEM review; PII exclusion	General	Section 8	Protecting SP-API applications — logging and monitoring
Vulnerability scans (30 days), pentest (annual), code scan pre-release	PII-Additional	Section 9	Vulnerability management
Amazon incident notification (security@amazon.com, 24 hours)	General	Section 13	Protecting SP-API applications — incident response