Back to Application

Security & Incident Response

Formal operating procedure for data protection and threat classification.

1. Scope

This protocol governs the explicit response actions required in the event of a suspected or confirmed compromise of user data, Personally Identifiable Information (PII), or associated Tax Authority OAuth tokens within the Pocket Bookkeeper Pro infrastructure.

2. Immediate Triage (0-24 Hours)

Upon discovery of an anomaly via automated telemetry, application logs, or via external white-hat disclosure, the Data Protection Officer (DPO) initiates an immediate environmental freeze:

  • Action: Invalidate all active user JWT sessions globally.
  • Action: Revoke all current Tax Authority OAuth Sandbox/Production access tokens associated with the identified breach vectors.

3. Statutory Authority Notification (24-72 Hours SLA)

Under strict adherence to GDPR and Tax Authority Digital Record Keeping Developer compliance, the DPO uniquely executes the following within 72 hours of verification:

Tax Authority Notification:

  • Method: Log a priority security ticket via the Tax Authority Developer Hub.
  • Data Exchanged: Scope of breach (Token compromise vs. PII), targeted timeframe, and technical remediation executions.
  • Primary Breach Contact: Tim Kay (Primary Architect / DPO).

Information Commissioner's Office (ICO) Notification:

  • Method: Self-report the personal data breach via the ICO online gateway.
  • Condition: Triggered instantaneously if the breach risks the rights and freedoms of individuals (e.g., Ledger financial data exfiltration).

4. User Notification & Sovereignty

Impacted users will be exclusively notified via high-priority email dispatch summarizing the specific vectors addressed, data affected, and forced-reauthentication requirements to restore account equilibrium.

5. Cryptographic Security & Encryption Controls

In strict alignment with the Information Commissioner's Office (ICO) Guidelines on Data Encryption, we natively deploy advanced cryptographic barriers to protect Personal Identifiable Information (PII) and financial ledgers against unauthorized interception or extraction:

  • Data in Transit (TLS 1.3): We aggressively enforce HTTP Strict Transport Security (HSTS). Every interaction between your local client, our application servers, and external third-party boundaries (such as the Tax Authority Developer Hub) is actively wrapped in modern TLS 1.3 cryptographic tunnels.
  • Data at Rest (AES-256): Our foundational database environments (Google Cloud / Firebase) operate on a 'secure-by-default' architecture. All raw physical files, immutable ledgers, structural document layers, and sensitive Tax Authority OAuth authorization keys are rigorously encrypted via military-grade Advanced Encryption Standard (AES-256) before touching physical storage disks.
  • Key Management: Our cryptographic keys are automatically rotated and managed independently by Google's native internal Cloud Key Management Service (KMS), intentionally distancing human personnel from decryption variables.

6. NCSC Compliant Multi-Tenant Isolation & Authentication

In order to provide absolute assurance that customer data cannot be laterally accessed by unauthorized concurrent users, our architecture adheres directly to the National Cyber Security Centre (NCSC) Cloud Security Principle 3: Separation Between Customers.

  • Mathematical Tenant Isolation: Our Firebase backend enforces zero-trust Security Rules at the database node level. Every single database transaction mathematically verifies that the querying user's cryptographically signed JWT identically matches the userId stamped on the target document. A user physically cannot request or pull another user's ledger data—the database actively rejects the request at the hypervisor level.
  • Modern Passwordless Authentication: Adhering to the NCSC guidelines on Updating Password Approaches, we specifically de-prioritize weak legacy passwords by actively funneling users toward modern WebAuthn architectures (Biometric Face ID / Touch ID) and delegated secure OAuth Identity Providers (Google Sign-In). This effectively neutralizes brute-force attacks and credential stuffing natively.

7. NCSC Personnel Security & Role-Based Access Control (RBAC)

In absolute accordance with the National Cyber Security Centre (NCSC) Cloud Security Principle 6: Personnel Security, we strictly regulate our internal engineering and operational architecture to prevent unauthorized employee access to customer data.

  • Strict Role-Based Access Control (RBAC): We deploy strict RBAC policies across our entire backend infrastructure. Customer support agents physically cannot execute database queries against production ledgers. High-level engineers only possess temporary, just-in-time (JIT) escalated privileges to access raw production environments when triaging explicit system-critical anomalies.
  • Zero-Knowledge Abstraction: Even when infrastructure access is granted, the raw financial abstractions (such as active ledger balances or categorized receipts) are mathematically insulated. We maintain a "Zero-Knowledge" philosophy where internal staff do not have the encryption keys required to decrypt your private financial documents or Tax Authority OAuth credentials.
  • Audit Logging: Every escalated internal query against the production database is cryptographically stamped and centrally logged. Any anomaly in employee access patterns triggers an immediate operational freeze and alerts the Data Protection Officer (DPO).

8. UK GDPR Individual Rights: Data Portability & Erasure

You are the absolute sovereign owner of your financial data. In strict accordance with the Information Commissioner's Office (ICO) Guidelines on Individual Rights, we provide entirely frictionless mechanisms to change, export, or permanently obliterate your records:

  • Right to Data Portability (Export): We absolutely guarantee your right to switch software providers without experiencing vendor lock-in. You can natively extract your entire Universal Ledger history, mathematically formatted into agnostic CSV or Excel (.xlsx) documents directly from your central dashboard at any time.
  • Right to Rectification (Change): Any mathematically extracted data generated by the AI Vision engine (such as automatic receipt VAT calculations) can be manually intercepted, re-categorized, or perfectly overridden by you prior to, and even after, saving it to your permanent ledger.
  • Right to Erasure (Deletion): Our operational architecture inherently supports destructive 'Right to be Forgotten' sequences. If you verify your credentials within the Account Security portal, you possess the capability to initiate a violent "Self Destruct" cycle. This recursively deletes your Firebase storage vaults, instantly severs Stripe billing tokens, and permanently purges your PII with absolutely zero residual footprint.

9. NCSC Compliant Penetration Testing & Vulnerability Management

Operating in direct accordance with the National Cyber Security Centre (NCSC) Penetration Testing Guidance, our infrastructure undergoes rigorous, continuous vulnerability validation frameworks to mathematically preempt exploits:

  • Automated SAST & DAST Pipelines: Our CI/CD deployment pipelines (managed via GitHub and Vercel) enforce automatic Static Application Security Testing (SAST) and Dependency Scanning. Code is mathematically rejected from deployment if known Common Vulnerabilities and Exposures (CVEs) exist within the underlying package architecture.
  • Dynamic Vulnerability Disclosure: Beyond automated toolsets, we natively enforce a Bug Bounty reporting protocol mapped to RFC 9116 (security.txt), encouraging independent third-party "White-Hat" penetration testers to actively audit our boundary defenses safely.
  • Edge Network Resilience: The application is fundamentally deployed across a distributed Edge Network natively protected by an enterprise Web Application Firewall (WAF) and automated DDoS mitigation protocols, absorbing and neutralizing brute-force and volumetric distributed attacks synchronously.

10. Continuous ICO Information Security Auditing

To legally ensure absolute protection of our technical controls and customer data, we conduct structured internal audits directly mirroring the ICO Information Security Checklist frameworks:

  • Formulated Review Schedules: Our documented Data Protection Policies (Privacy, Incident Response, Cryptography, RBAC) undergo aggressive internal audits bi-annually and immediately following major architectural deployments to ensure evolving compliance against emerging UK GDPR legal vectors.
  • Automated Telemetry Logging: We do not rely solely on manual periodic reviews. Advanced continuous telemetry logging actively audits our security posture in real-time. Any unverified administrative or infrastructure behavior within our Google Cloud architecture triggers immediate programmatic alert chains.
  • Sub-Processor Accountability: As the primary Data Controller, we strictly audit our core sub-processors (Stripe, Vercel, Firebase) ensuring they physically maintain external ISO 27001, SOC 2 Type II, and PCI Level 1 compliance structures before they are legally permitted to interface with our network boundary.

11. Tax Authority Advanced Fraud Prevention Telemetry

In strict compliance with the Tax Authority Fraud Prevention Specification, our application architecture fundamentally operates as a WEB_APP_VIA_SERVER. We natively intercept and attach critical device-level telemetry to every single outgoing API request established with the United Kingdom Government Gateway.

  • Gov-Client-Public-IP & Device-ID: We capture underlying hardware heuristics, screen resolutions, cryptographically salted device identifiers, and localized IPv4/IPv6 origination vectors. These are securely transmitted to Tax Authority specifically to detect malicious proxy routing or man-in-the-middle credential hijacking algorithms.
  • Gov-Vendor Architectural Integrity: We physically stamp all Digital Records API requests with our proprietary Vendor Version and public routing Edge IPS, creating an explicit, undeniable digital signature mathematically verifying that the data packet originated exclusively from secured Pocket Bookkeeper Pro servers.
  • Data Privacy Designation: This specific cross-site telemetry is utilized exclusively as a 'Zero-Trust' anti-fraud validation mechanism during live Tax Authority transmissions. We do not permanently store this raw hardware fingerprint data offline, nor do we monetize or sell it to third-party data brokers.

Vulnerability Disclosure Standard (RFC 9116)

We actively encourage security researchers to audit our boundary defenses. We natively host a formal security.txt protocol mapping file.

Contact: mailto:support@pocketbookkeeper.co.uk
Canonical: https://pocketbookkeeper.co.uk/.well-known/security.txt