# Security self-assessment (SIG-Lite / CAIQ-Lite) — TW Market Data (TWMD) v1 · Answers current as of 2026-08-19 > This is the pre-filled security questionnaire we hand to an institutional buyer's procurement or security team, published rather than emailed on request. It follows the shape of SIG Lite and CAIQ Lite so it can be read beside the ones you already have. > > It is a self-assessment. It has not been audited by a third party, and where it touches a legal contract — data processing terms in particular — the version reviewed by counsel governs. Items are marked as implemented, in progress, or on the roadmap; nothing is marked implemented that we cannot show evidence for. > > One thing shapes most of the answers below: TWMD is a platform for first-hand official public disclosure. The data we sell contains no personal data and no material non-public information, so the breach risk we present to a buyer is structurally low, and several questions that dominate a normal vendor review are narrow here as a result. ## A. Company and governance ### A1. What is the business? A Taiwan market data platform covering TWSE, TPEx, TAIFEX, TDCC and MOPS, plus open macroeconomic series. API-first, built for quantitative research and AI agents. ### A2. Legal entity and governing law Operated under the name TW Market Data (TWMD), founder-run. Governing law and jurisdiction: the Republic of China (Taiwan). The contracting party is confirmed at contract stage. ### A3. What is your data processing role? For the market data itself, the question does not arise: it contains no personal data. For account and billing records, the customer is the controller and TWMD is the processor. ## B. Data and privacy ### B1. Does the data contain material non-public information? — **Implemented** No. Every series originates in official public disclosure. There is no insider-sourced and no expert-network component anywhere in the catalogue. ### B2. Does the data contain personal data? — **Implemented** No. The holding data from TDCC is an aggregated distribution across holder bands, not the identity of any individual holder. ### B3. Where does the data come from? — **Implemented** First-hand from the official publishers — TWSE, TPEx, TAIFEX, TDCC, MOPS — plus open macroeconomic sources. A per-dataset register of source and licence is maintained and published. ### B4. May we redistribute it? — **Implemented** The core datasets are redistributable under Taiwan's Open Government Data License v1, with attribution required. The determination is made per dataset, not blanket, and the current split is 103 clear, 20 conditional and 2 not redistributable. ### B5. GDPR / CCPA posture — **In progress** The data content triggers no data-subject obligations, because it contains no data subjects. The privacy documentation covering account and billing data is written and published; the processing agreement is with counsel. ## C. Access control and authentication ### C1. How is API access authenticated? — **Implemented** API keys, with entitlement scoped by plan. Keys are issued to and held by the customer; they do not leave the customer's environment. ### C2. How is internal access controlled? — **Implemented** Least privilege, with the read-only monitoring role separated from the application credential so that observability does not carry write access. ### C3. How do end users sign in? — **Implemented** GitHub OAuth, passkeys, and the RFC 8628 device authorization flow for terminals. Credentials are stored hashed only. ### C4. How fast can a key be revoked? — **Implemented** Customer keys are held in the database as a SHA-256 digest with a status field. Revocation takes effect on the next request — there is no cached grant to expire. ## D. Encryption ### D1. Encryption in transit — **Implemented** TLS, graded A+ by Qualys SSL Labs across four endpoints: HSTS enabled, TLS 1.2 and 1.3 only, 1.0 and 1.1 refused, no RC4, forward secrecy throughout. Anyone can re-run that test against us. ### D2. Encryption of backups at rest — **Implemented** Backups are encrypted with age before they leave the host. ### D3. Database encryption at rest — **Roadmap** Not implemented. On the roadmap, and listed as such rather than answered with the backup encryption above, which is a different control. ## E. Infrastructure and network ### E1. Where is it hosted? — **Implemented** Self-hosted, which keeps data sovereignty with us rather than with a managed platform: compute at Contabo in Japan, with Cloudflare at the edge providing WAF and DDoS protection. ### E2. Application-layer protections — **In progress** Parameter-bound queries, SSRF blocking of private and metadata address ranges, and namespace-level authorization isolation. These are stated as design principles: they are implemented, and they have not been validated by a third party, so they are not claimed as tested. ### E3. Environment separation — **In progress** Production is separated from preview deployments, with separately scoped credentials. Formal documentation of the boundary is not written. ## F. Backup, DR and continuity ### F1. What is backed up, and where? — **Implemented** Daily encrypted off-site backups to Cloudflare R2. ### F2. Has a restore ever been tested? — **Implemented** Yes — a restore drill was performed with the real keys, not a dry run against a dummy archive. It is recorded in the Trust Center updates feed with its date and measured duration. ### F3. What is the recovery point objective? — **In progress** Daily snapshots, so the worst case is approximately 24 hours of loss. That is the honest figure, and it is the one that improves when point-in-time recovery lands. ### F4. Point-in-time recovery — **Roadmap** Not implemented. Planned via pgBackRest with WAL archiving, which is what would reduce the RPO above. ## G. Vulnerability and change management ### G1. Code review, static analysis, dependency scanning — **Implemented** All three run as routine practice rather than as a periodic exercise. Dependency scanning is scheduled weekly — pip-audit, osv-scanner and Dependabot — and is informational: it reports, it does not block a build. This answer is about whether scanning HAPPENS. Whether what it finds has been fixed is a separate question, answered at G2 and in the ASVS mapping, and the two were once worded so similarly that they read as a contradiction. ### G2. Are there known unpatched vulnerabilities? — **In progress** Yes: approximately 16 open dependency CVEs as of 2026-08-19, none in a path that handles customer credentials. The count is published rather than the list — a count cannot be acted on by an attacker, an enumeration can. We would rather disclose an unflattering number than answer this question with a clean one. ### G3. Third-party penetration testing — **Roadmap** None has been performed. It is on the roadmap and it is not claimed anywhere on this site as done. ## H. Logging and monitoring ### H1. What is monitored? — **Implemented** An external status page (Uptime Kuma) plus internal Prometheus and Grafana covering route latency, cron success, data freshness and database health. ### H2. How are incidents disclosed? — **Implemented** On the public status page, named, with cause, impact and a time window — including the periods where no sample was taken. The practice predates this document; the outage write-up is on the page now. ## K. Verifiable data ### K1. Can a buyer prove the history was not altered? — **Implemented** Yes. Each published snapshot commits to a cryptographically signed Merkle checkpoint, exposed through four public proof endpoints, and verified by a standard-library script the buyer runs themselves. The honest boundary: it proves integrity and origin, not semantic correctness, and it is not a proof of when a computation occurred. ## I. Subprocessors 6 suppliers, covering compute, CDN and WAF, encrypted backup, payments, transactional email, sign-in and analytics. The maintained list is at https://twmarketdata.com/en/trust. The payments provider touches no market data. - **Cloudflare** — All HTTP traffic to the site and API, including request IP addresses - **Cloudflare R2** — Full database dumps, which include account records - **Contabo** — Everything the platform runs and stores - **Polar** — Customer identity and billing details - **Resend** — Email addresses and message contents - **Google** — Identity at sign-in. Analytics loads only after an affirmative choice and never before. ## J. Certification status No third-party certifications are held. The roadmap below is the one published on the Trust Center. ### HSTS preload listing — **Roadmap** Free, and not done. It needs the preload directive added to the header and a submission. Worth knowing before it is: preload is close to one-way — removal from the list takes months to reach browsers, so it is submitted once the header is settled, not to tick a box. ### GDPR documentation posture — **Roadmap** Not a certification: a set of documents — privacy policy, DPA template, data-subject request process. Free to produce and not yet produced. Listed because an enterprise buyer asks for them by name. ### CAIQ / SIG Lite self-assessment — **Roadmap** The standard questionnaires a buyer's security team sends. Free to complete, and completing one is the honest halfway house to a formal audit: it produces answers we can hand over, without claiming an attestation nobody performed. ### SOC 2 Type 1 — **Roadmap** The first certification that costs money: an auditor, and usually a compliance monitoring tool. Type 1 covers a point in time rather than an observation period, which is why it is normally the first one a company obtains. Not started. --- This is a self-assessment, not a third-party audit. Where it touches a legal contract, the version reviewed by counsel governs. Generated from https://twmarketdata.com/en/trust/self-assessment