Security Policy

This page describes how The Financial Playbook, the operator of CreditTrack, approaches information security for the CreditTrack application and website. It is maintained by us as the owner of the product and is reviewed as the product changes.

Scope and ownership

This policy covers the CreditTrack web application, its database, and the third-party services we rely on to run it. The Financial Playbook is responsible for keeping this policy current and for the security decisions described here. Security questions can be sent to info@credittrack.co.

Encryption in transit

Yes. All traffic between your browser and CreditTrack is encrypted in transit using HTTPS with TLS 1.2 or higher. Our live site negotiates TLS 1.3, and we enforce HSTS (HTTP Strict Transport Security) so browsers always reconnect over HTTPS.

Connections from the CreditTrack application to its backend database and to third-party services such as our payment processor and email provider are also made over encrypted transport.

Encryption at rest

Yes. All consumer data we receive through our bank and card connection provider — including linked account identifiers, balances, account metadata, and any liability or payment information — is stored in the CreditTrack database. The database uses provider-managed encryption at rest (AES-256) for both storage volumes and automated backups, so every row is covered, not only selected sensitive fields.

Access tokens used to maintain an optional bank or card connection are stored server-side only and are never returned to the browser.

What we collect — and what we never ask for

CreditTrack works from information you choose to enter: your card nicknames, balances, credit limits, statement and due dates, and the payments you plan. We never ask for full credit card numbers, CVV codes, PINs, or your online banking password, and there is nowhere in the app to enter them.

Payments for your membership are handled by our payment provider, which is the merchant of record. Your card details are entered with that provider and are not stored by CreditTrack.

If you choose to connect a bank or card account for automatic balance updates, that connection is handled by a specialist connection provider. The connection is optional, you choose which accounts to include, and you can unlink it at any time from Settings.

Multi-factor authentication for members

Yes. CreditTrack requires two-step verification before a bank or card connection can be created, changed, or removed, and before all of your data can be deleted.

We email a 6-digit code to the address on the account; each code is valid for ten minutes, works once, and is stored only in scrambled form. Repeated incorrect entries and repeated requests are both limited, and one successful entry covers a short window so members are not prompted repeatedly.

You can confirm delivery at any time by sending a test code from Settings → Two-step verification.

How we identify and reduce risk

• Two-step verification is enforced on the server for bank connection actions, not only in the app's screens.
• Access to your data requires you to be signed in, and the database enforces per-account access rules so one member's records cannot be read or changed by another.
• Administrative capabilities are separated from ordinary member accounts and are checked on the server, never trusted from the browser.
• Credentials and provider keys are held as server-side secrets and are not shipped to the browser.
• Changes to the application are reviewed against automated checks, including security and dependency scanning, before they go live, and findings are triaged and tracked to closure.

Access and identity

CreditTrack uses centralized identity and access management. Every sign-in, session, and role assignment runs through one managed authentication service — there are no separate local logins, and there is no “trusted” internal traffic that can reach member data without passing the same checks.

Access control follows a defined and documented policy, summarized on this page: role-based access, least-privilege rules on every database table, server-side-only credentials, and admin capabilities separated from ordinary member accounts. These rules are enforced by the database itself, not only by the app's screens.

Privileged access is limited to a small admin role. Admin membership is reviewable in the admin dashboard at any time and is reviewed periodically; removing someone's access takes effect immediately across all systems.

Authentication relies on short-lived, signed session tokens with automatic rotation. Bank connection credentials are exchanged through our connection provider and stored server-side only — they are never readable by the browser. All traffic is protected with TLS 1.2 or better (TLS 1.3 with HSTS in practice).

On the consumer-facing application, robust multi-factor authentication is required before a bank or card connection can be opened, changed, or removed, and before all data can be deleted — see “Multi-factor authentication for members” above for the details.

Vulnerability management

Program classification. This is a vulnerability management and security testing program. It covers scanning, severity classification, internal remediation service-level targets, and end-of-life monitoring of the technology we use. The remediation targets described below are our internal commitments for fixing security findings; they are not a contractual service-level agreement about uptime or support response times, and end-of-life here refers to the software we depend on, not to CreditTrack itself.

We do not directly operate vulnerability scans against employee or contractor laptops, or against individual production server instances. CreditTrack is built and operated by a small product team, and the underlying infrastructure (compute, storage, networking, and host-level patching) is managed by our cloud platform provider.

What we do manage at the application level is scanned automatically as part of our deployment workflow. Every change, every merge to our release branch, and a daily scheduled re-scan run two automated scans:

• Dependency scanning — all production dependencies are checked against published vulnerability advisories, including packages pulled in indirectly.
• Application scanning — static analysis of our own code, plus automated checks for credentials or secrets accidentally committed to the codebase.

These scans are enforced with severity thresholds. Any finding rated critical fails the pipeline and blocks the release from being deployed until it is resolved. Scan reports are retained for each release, and we monitor application errors and failed requests on an ongoing basis.

Patching within a defined SLA

Yes. Identified vulnerabilities are classified by severity and remediated within documented service-level targets, measured from the date the vulnerability was first identified:

• Critical — 7 days, and the release is blocked immediately on discovery.
• High — 30 days.
• Medium — 90 days.
• Low or informational — 180 days.

Critical and high-risk findings take priority over feature work. Each finding is recorded in a findings register with the date it was identified, its severity, its remediation deadline, the action taken, and the date it was resolved. Our automated checks reconcile that register on every run and raise alerts for newly identified findings, findings due within seven days, and findings that have passed their deadline — a finding past its deadline fails the pipeline and blocks the release until it is closed or covered by a documented exception with a review date. Vulnerabilities reported to us from outside these scans are entered in the same register under the same severity and deadline rules.

End-of-life software monitoring

Yes. We maintain an inventory of the technology CreditTrack uses — the application runtime and language, framework and build tooling, the database, managed platform services, the payment, email, and bank-connection provider APIs, and every library shipped in production. Each entry records the version in use, the vendor-published end-of-support date where one exists, and who is responsible for its lifecycle.

• A component past its end-of-support date is treated as a blocking finding and must be upgraded, replaced, or covered by a documented exception with a review date.
• A component within 180 days of end-of-support is flagged so the upgrade is scheduled before support ends.
• New end-of-life or unsupported software cannot be introduced into production: a change that adds or moves to an unsupported version fails our automated checks, as does a production dependency that is missing from the inventory.
• Monitoring and remediation activity is recorded with dates, and the inventory is reviewed monthly in addition to the automated daily check.

Components whose vendors publish no fixed end-of-support date are monitored for release-line deprecation and kept on a currently maintained major version. Operating systems, container images, host-level patching, and database major-version lifecycles are operated by our managed cloud platform provider; for those we monitor and act on the provider's deprecation notices rather than patching the infrastructure ourselves.

These are operating controls with retained records, not statements alone. If you need the underlying procedure document or evidence for a vendor review, contact us at info@credittrack.co.

Monitoring and response

We monitor application errors, failed requests, and security scan results on an ongoing basis. When an issue is identified, we assess its impact, apply a fix, and verify the fix before closing it. If an incident were to affect your personal information, we would notify affected members and take the steps required of us by applicable law.

Your control over your data

You can edit or delete any card, plan, or balance you have entered, unlink a connected account, and delete everything you have entered from Settings → Delete my data. See our Privacy notice for how your information is used.

Reporting a security issue

If you believe you have found a vulnerability in CreditTrack, please email info@credittrack.co with enough detail for us to reproduce it. Please do not access, modify, or delete data belonging to other people while testing. We will acknowledge your report and keep you updated while we investigate.

What this page does not claim

This page describes our own practices. It is not an audit report and does not claim any third-party certification, attestation, or regulatory compliance status. If you need documentation for a vendor review, contact us at info@credittrack.co.