Security & Trust
A comprehensive technical overview of how RecordIQ protects your data through offline architecture, FIPS 197-approved encryption, tamper-evident audit trails, and designed with HIPAA safeguards in mind safeguards.
For NIST SP 800-171 control mapping and government compliance: Government & Public Sector Compliance
Architecture Overview
RecordIQ is engineered as a primarily offline, standalone application. Every component of the software — OCR engine, document classifier, chronology builder, encryption layer, audit system, and license validator — runs entirely on your local workstation.
All document processing — OCR, classification, extraction, encryption — operates entirely offline with no network connections. The only optional network activity is a user-initiated version check to recordiq.app (HTTPS, no PHI transmitted). No telemetry, no cloud API calls, no background data uploads.
Verification: You can confirm offline operation by running RecordIQ on an air-gapped machine (no network adapter) or behind a firewall that blocks all outbound traffic. Every document processing feature will function identically. The optional version check will simply be skipped.
All input data (PDFs, images) is read from a local folder you select. All output data (Excel reports, encrypted files, audit logs) is written to a local output directory. At no point does any data leave your machine through RecordIQ.
Data Flow Summary
Input: Local folder → PDFs, TIFFs, PNGs, JPEGs from your filesystem
Processing: Tesseract OCR engine, classification models, extraction algorithms — all running locally
Output: Encrypted Excel reports, encrypted text files, audit logs → local output directory
Network: Optional version check only (HTTPS to recordiq.app, no PHI). All processing is offline.
Advanced Pattern Matching Engine
The Advanced Pattern Matching engine (spaCy NLP) runs entirely locally. No text is transmitted externally. The NLP model (~40MB) is bundled with the application installer. All pattern matching is deterministic — the same input always produces the same output.
Like every other component in RecordIQ, the NLP engine operates within the zero-network architecture. It requires no internet connection, makes no API calls, and stores no data outside the local workstation. The bundled model is read-only and does not update or phone home.
Encryption
All output files produced by RecordIQ are encrypted using AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode). AES-256 is approved by NIST (FIPS 197) and is widely adopted across government and financial institutions for protecting sensitive data.
GCM mode provides both confidentiality and authenticity. Every encrypted file includes an authentication tag that detects any modification to the ciphertext, preventing tampering attacks. If even a single bit is altered, decryption will fail and the integrity violation will be flagged.
Encryption Parameters
Algorithm: AES-256-GCM (authenticated encryption with associated data)
Key length: 256 bits (32 bytes), generated from a cryptographically secure random source
Nonce: 96-bit (12-byte) random nonce, unique per encryption operation
Authentication tag: 128-bit GCM tag for integrity verification
Key storage: Keys are stored locally on your workstation and never leave the machine
Every encrypted file is stored in JSON format containing three fields: the random nonce, the GCM authentication tag, and the ciphertext. This self-contained format ensures each file carries everything needed for decryption (except the key itself).
After encryption completes, the plaintext version of each output file is securely deleted using a multi-pass overwrite (see Secure Disposal). Only the encrypted version remains on disk.
Access Controls
RecordIQ provides an optional application-level PIN lock to prevent unauthorized access to the software and its processed data, even when the underlying Windows session is unlocked.
PIN Key Derivation
Algorithm: PBKDF2-HMAC-SHA256 (Password-Based Key Derivation Function 2)
Iterations: 600,000 rounds — exceeding the OWASP 2023 recommendation of 600,000 for SHA-256
Salt: Cryptographically random, unique per installation
Storage: Only the derived hash and salt are stored. The raw PIN is never saved to disk.
The high iteration count ensures that even if an attacker obtains the stored hash, brute-forcing the PIN is computationally infeasible with current hardware.
- Auto-lock on inactivity — the application automatically locks after a configurable period of inactivity, requiring re-entry of the PIN
- Lock on minimize/switch — optional setting to lock whenever the application loses focus or is minimized
- No backdoors — there is no master key, recovery code, or remote unlock capability; if the PIN is forgotten, the hashed credential must be reset locally
Audit Trail
RecordIQ maintains a tamper-evident, append-only audit log that records every processing action, file operation, and significant application event. This log is designed to support HIPAA's audit control requirements under the Security Rule (45 CFR § 164.312(b)).
Chain Integrity Mechanism
Algorithm: HMAC-SHA256 chained hashing
How it works: Each log entry includes an HMAC-SHA256 hash computed over the entry's content concatenated with the hash of the previous entry. This creates a cryptographic chain — similar to a blockchain — where altering any entry invalidates all subsequent hashes.
Tamper detection: On startup and on demand, RecordIQ verifies the entire chain. If any entry has been modified, inserted, or deleted, the hash chain breaks and the application flags the exact point of tampering.
Audit logs can be optionally encrypted with the same AES-256-GCM mechanism used for output files, providing confidentiality for log entries that may reference filenames or processing metadata.
- Append-only design — log entries can only be added, never modified or deleted through the application
- Timestamps — every entry includes a local timestamp for regulatory reporting
- Event categories — file processing, encryption operations, decryption access, PIN changes, application start/stop, and configuration changes
- PHI-safe logging — audit entries are filtered to exclude PHI content (see PHI Protection)
PHI Protection
RecordIQ detects and can redact 40+ types of sensitive information directly within your documents — including all 18 HIPAA Safe Harbor identifiers, financial PII (credit cards, bank accounts), privilege markers, trade secrets, and Canadian identifiers (SIN, OHIP). PHI redaction produces production-ready PDFs with black-box redactions applied to detected identifiers, designed for professional review.
Beyond redaction in PDF output, RecordIQ applies multi-layer PHI protection across the entire processing pipeline:
- Log filtering — audit log entries are automatically scrubbed to prevent PHI from appearing in log text; detected identifiers are replaced with category placeholders (e.g.,
[SSN],[DOB]) - Metadata scrubbing — output files have PDF metadata, EXIF data, and other embedded metadata stripped to prevent unintended PHI leakage through document properties
- Redaction audit report — a detailed report is generated listing every redaction applied, its type, page number, and confidence level, for compliance documentation
Secure Disposal
When RecordIQ deletes temporary files or removes plaintext after encryption, it does not simply mark the file as deleted in the filesystem. Standard deletion leaves data recoverable with forensic tools, which is unacceptable when handling PHI.
Instead, RecordIQ performs a 3-pass random overwrite before unlinking the file from the filesystem:
Overwrite Procedure
Pass 1: Overwrite entire file contents with cryptographically random bytes
Pass 2: Overwrite with a second round of fresh random bytes
Pass 3: Overwrite with a third round of fresh random bytes
Final step: Flush to disk, then delete the file from the filesystem
This approach ensures that the original plaintext content is irrecoverable using standard forensic recovery tools. The 3-pass method exceeds the disposal requirements for most compliance frameworks, including NIST SP 800-88 guidelines for media sanitization of non-magnetic storage.
When secure disposal is applied: Plaintext output files after encryption, temporary files created during OCR processing, and any intermediate working files generated during document analysis.
No PHI Transmitted During Processing — Zero Trust Architecture
RecordIQ is built on a Zero Trust Network Access (ZTNA) model. All document processing, OCR, analysis, and report generation run entirely on the user's workstation. Patient data (PHI) is not transmitted over any network during document processing.
- No PHI transmitted — patient records, OCR output, analysis results, and audit logs never leave the workstation. AES-256-GCM encrypted files remain local.
- No telemetry — no usage analytics, crash reporting, feature tracking, A/B testing, or behavioral data collection of any kind
- Optional update checks — the application can check for newer versions via HTTPS. This is disabled by default and transmits only the current version number. No document data or PHI is transmitted.
- No cloud processing — OCR, NLP, classification, redaction, and all analysis occur locally. No documents or extracted text are sent to external services.
Zero Trust Authentication: Every connection RecordIQ makes requires explicit authentication via license key + hardware-bound machine ID. No implicit trust is granted to any request. License validation is performed server-side with machine binding; the license key is never transmitted without machine verification.
Optional Support Diagnostics: Users may optionally submit a support diagnostic report via the Help menu. Before transmission, the application automatically scans and redacts all PHI patterns from log files. The diagnostic zip contains only system information and sanitised application logs — never patient records or OCR output. Transmission is user-initiated, authenticated, rate-limited, and encrypted in transit (TLS 1.2+).
HIPAA Alignment Summary
The HIPAA Security Rule (45 CFR Part 164, Subpart C) establishes three categories of safeguards that covered entities and business associates must implement. The table below maps RecordIQ's security controls to each applicable HIPAA requirement.
| Safeguard | HIPAA Requirement | RecordIQ Implementation |
|---|---|---|
| Technical | Access Control (§ 164.312(a)) |
Optional PIN lock with PBKDF2-SHA256 (600K iterations); auto-lock on inactivity; no default passwords |
| Technical | Audit Controls (§ 164.312(b)) |
Tamper-evident HMAC-SHA256 chained audit log; records all file access, processing events, and configuration changes |
| Technical | Integrity Controls (§ 164.312(c)) |
AES-256-GCM authentication tags detect any modification to encrypted files; HMAC chain detects log tampering |
| Technical | Transmission Security (§ 164.312(e)) |
PHI is never transmitted. Optional support diagnostics are auto-scrubbed of all PHI before transmission, user-initiated, and use TLS 1.2+ |
| Technical | Encryption at Rest (§ 164.312(a)(2)(iv)) |
AES-256-GCM encryption for all output files; plaintext securely deleted after encryption |
| Physical | Workstation Security (§ 164.310(c)) |
All processing runs locally; no document data leaves the workstation; application-level PIN lock; auto-lock on idle |
| Physical | Device & Media Controls (§ 164.310(d)) |
3-pass secure disposal of temporary and plaintext files; encrypted output format for safe media transfer |
| Administrative | Security Management (§ 164.308(a)(1)) |
Zero-network architecture significantly reduces entire categories of risk; no cloud vendor dependencies; no third-party data processors |
| Administrative | Information Access Management (§ 164.308(a)(4)) |
Per-workstation licensing; application-level access control; encryption keys stored per-installation |
| Administrative | Contingency Plan (§ 164.308(a)(7)) |
Local key backup guidance; encrypted output files portable for disaster recovery; no cloud dependency means no vendor lock-in |
| Administrative | Business Associate Agreements (§ 164.308(b)(1)) |
BAA available upon request for covered entities; contact support@recordiq.app |
Important note: HIPAA compliance is a shared responsibility. RecordIQ provides the technical safeguards described in this document, but covered entities remain responsible for their own administrative policies, workforce training, physical security of workstations, and organizational compliance programs. RecordIQ does not provide legal advice; consult your compliance officer or HIPAA counsel for guidance specific to your organization.
Questions About Security?
Our team is available to discuss RecordIQ's security architecture and compliance documentation.