Data Security

Registry Intelligence applies risk-based technical and organizational safeguards to its public website, protected commercial intelligence modules, payments, accounts, compliance applications, uploaded files, temporary processing jobs, and generated downloads.

This page explains the security principles used for active Services and the minimum release requirements for new Registry Intelligence applications. Controls are selected according to the information processed, the product architecture, the sensitivity and duration of storage, the threat model, and the operational purpose of each Service.

No website, software system, cloud service, encryption method, or organizational control can guarantee absolute security. Registry Intelligence therefore uses layered controls, limits the information collected, separates unrelated products, keeps high-risk processing out of the public WordPress layer, and stops a new application from accepting live files or payments until its required security gates have been passed.

1. Scope and security principles

This security framework covers the Registry Intelligence website and Services operated by Poland Documents, including public pages, WordPress administration, MemberPress-controlled access, protected browser interfaces, commercial intelligence modules, compliance applications, file-processing services, Stripe payment flows, generated output, support operations, and the infrastructure used to deliver those functions.

Registry Intelligence applies the following principles:

• Data minimization: collect and retain only the information reasonably necessary for the stated Service.
• Separation: keep public content, paid modules, compliance processing, payments, and administrative functions within defined boundaries.
• Least privilege: grant users, services, workers, databases, and administrators only the access required for their role.
• Defense in depth: use multiple complementary controls instead of relying on a single file check, password, firewall, or encryption layer.
• Secure defaults: deny protected access unless authorization is confirmed and avoid public exposure of files, tokens, secrets, or administrative status.
• Short-lived processing: treat uploaded compliance files and generated packages as temporary job data rather than permanent document storage.
• Verified change: test software, dependency, infrastructure, and regulatory-rule changes before production activation.
• Fail closed: stop sensitive processing, payment, generation, or download where required authorization, payment, rule freshness, or integrity checks fail.
• Honest assurance: describe controls accurately and do not claim security certifications, guarantees, or audit results that have not been obtained.

2. Categories of data and security treatment

Public website content

Public pages, regulatory guides, market pages, product descriptions, and source explanations are intended for public access. Public availability does not permit unauthorized editing, automated abuse, scraping of protected products, or interference with the website.

Official-source module data

Commercial intelligence modules are built from selected official-source and lawfully accessible public-source records. Although individual source records may be public, the structured modules, annotations, normalized fields, protected interfaces, account access, and paid downloads remain controlled products. Public-source status does not remove the need for access controls, provenance protection, integrity checks, and license enforcement.

Account and access data

Account information may include name, business email, organization, role, login status, access entitlements, purchase history, session information, and security events. These records are limited to the functions required for authentication, authorization, billing, support, fraud prevention, and administration.

Payment and invoice data

Payments are processed through Stripe or another provider identified at checkout. Registry Intelligence receives payment status, transaction references, customer and billing information required for delivery, reconciliation, support, invoicing, accounting, and fraud prevention. Complete payment-card details must not be uploaded to Registry Intelligence applications or sent by email.

Uploaded compliance files

Compliance applications may accept supported CSV, XLSX, text-based PDF, XML, or other specifically listed formats. These files may contain product, manufacturer, laboratory, testing, certificate, trade-party, facility, shipment, or other business records. Uploaded files are treated as user-controlled temporary processing data and are not added to commercial intelligence modules, public datasets, or unrelated customer products.

Generated files and reports

Output may include readiness reports, completion workbooks, working copies, validated CSV files, calculations, document packages, README files, and protected ZIP downloads. Generated files may contain the same business information as the uploaded source and therefore receive protected access and defined expiration or deletion handling.

Operational metadata and logs

Security and operational records may include timestamps, job identifiers, status transitions, file size and type, row counts, validation outcomes, payment references, download events, error codes, IP or request metadata, and administrative actions. Logs should avoid raw uploaded content, complete authentication tokens, secrets, and payment-card data.

3. Architecture and product separation

Registry Intelligence separates public publishing from sensitive application processing. WordPress provides public pages, navigation, guides, product explanations, and entry points. Compliance-file validation, temporary jobs, paid generation, regulatory-rule handling, and protected downloads are not implemented inside a general WordPress content plugin.

Compliance applications use a separately controlled backend runtime, configuration, storage, logging, background processing, and deployment boundary. This reduces the risk that a file parser, job failure, payment event, or application dependency affects WordPress, MemberPress, city intelligence modules, or unrelated products.

MemberPress-controlled city-module access and compliance-application access are treated as separate authorization domains. A city-module membership does not automatically grant access to compliance jobs, and a compliance-app payment does not grant access to commercial intelligence modules.

New applications should use separate service credentials, scoped database access, isolated storage paths, defined network routes, restricted administrative interfaces, and independent payment-session metadata. Global WordPress, PHP, Python, web-server, or system-library changes are not made solely to satisfy a new application dependency where an isolated runtime can be used.

4. Transport security and encryption

Registry Intelligence uses HTTPS to protect data transmitted between supported browsers and the website. Application and administrative endpoints must be served through valid TLS configuration before live use. Users should not bypass browser certificate warnings or submit files through an unencrypted connection.

Sensitive compliance-job payloads that require temporary storage must use encryption appropriate to the application design. Encryption keys and service secrets must be separated from uploaded files and source code, restricted to authorized runtime identities, and managed through controlled configuration rather than hard-coded into public files or repositories.

Encryption reduces exposure risk but does not replace authorization, secure key handling, deletion, patching, monitoring, backups, or user-side security. Data may be decrypted temporarily in application memory when required for validation, generation, or authorized delivery.

5. Access control and administrative security

Protected resources use authorization checks designed to deny access unless the relevant account, role, entitlement, job ownership, payment state, or secure-download condition is confirmed. Knowledge of a URL alone must not be treated as sufficient authorization for an administrative page, protected module, uploaded file, or generated package.

Administrative access is restricted to authorized personnel and functions. Controls may include unique credentials, strong passwords, multifactor authentication where supported, role-based permissions, limited database rights, separate service identities, restricted server access, session controls, security logging, and revocation procedures.

Authentication tokens, payment identifiers, job secrets, and protected access credentials should not be exposed in public page content, analytics, browser local storage, referrer URLs, support screenshots, or logs beyond what is technically necessary and appropriately protected.

Access is removed or adjusted when no longer required, when a credential is suspected to be compromised, when a subscription or license ends, or when use violates the Terms of Use.

6. File-upload security

File upload creates risks that do not exist on ordinary content pages. A live Registry Intelligence upload service must use layered controls appropriate to the allowed formats and processing libraries.

Depending on the application and file type, controls may include:

• an allowlist of business-required extensions and formats;
• file-size, row-count, page-count, column-count, archive, and processing-time limits;
• validation of extension, declared content type, file signature, and parse result rather than trusting a browser header alone;
• application-generated internal filenames and protection against path traversal, overwrite, hidden-file, and unsafe-character behavior;
• storage outside publicly served directories or delivery through an authorization-controlled handler;
• read-only or restricted parser modes where supported;
• protection against XML external entities, oversized expansion, malicious archives, decompression bombs, formula injection, active content, and malformed structures;
• rejection of executable files and formats not required for the stated workflow;
• malware scanning where available and proportionate, without representing any scanner as a complete guarantee;
• safe error handling that does not expose server paths, secrets, stack traces, or another user’s information;
• rate, concurrency, storage, and job limits designed to reduce denial-of-service risk.

Uploaded files are parsed as data; they are not intentionally executed. A supported extension does not guarantee that a file will be accepted. A file may be rejected if its structure, signature, contents, size, encoding, complexity, or security characteristics do not satisfy the active application rules.

The initial CPSC eFiling workflow is designed to process supported files without OCR and without sending uploaded content to an AI model as part of the core validation and generation flow. Any future use of OCR, AI, or an external document-processing provider would require separate review, updated disclosure, appropriate contractual controls, and a defined user-facing purpose before activation.

7. Temporary jobs and processing workflow

A compliance application organizes uploaded files, mappings, corrections, validation state, payment state, and output under a temporary job identifier. Job ownership and authorization are checked before sensitive actions.

A typical protected workflow is:

1. the user opens the authorized application interface;
2. supported source files are uploaded through HTTPS;
3. file type, limits, structure, and parser safety checks are applied;
4. data is mapped and validated within the isolated application workflow;
5. the user reviews errors, missing information, mapping, and ready records;
6. the backend recalculates scope, price, authorization, and regulatory-rule freshness before payment;
7. the payment provider confirms the event through a verified server-side webhook;
8. authorization, payment, selected records, and regulatory freshness are checked again after payment;
9. a background worker generates the authorized output;
10. the user receives a protected download;
11. temporary source, job, and output data are deleted according to the disclosed retention window.

Client-side indicators are not treated as authoritative for payment, price, row selection, authorization, or rule version. Sensitive decisions are repeated server-side to reduce tampering, stale-state, and replay risks.

8. Generated files and protected downloads

Generated packages are not placed in publicly browsable folders. Delivery uses authorization-controlled access, unpredictable identifiers, limited availability, or another protected mechanism appropriate to the Service.

Download authorization may be tied to job ownership, payment status, expiration, permitted download state, or a secure one-time or time-limited token. Download links should not be shared publicly, forwarded to unauthorized recipients, stored in public documents, or submitted to third-party scanning services without considering the data involved.

Users are responsible for downloading results within the displayed availability period, storing them safely, controlling onward sharing, and deleting local copies when no longer needed. Registry Intelligence does not provide permanent document storage unless a product explicitly says otherwise.

9. Payment security

Registry Intelligence uses Stripe Checkout or another clearly identified hosted payment flow for applicable purchases. Complete card details are entered into the payment provider’s environment rather than uploaded to a compliance job or intentionally stored by Registry Intelligence.

Payment integration uses server-created checkout sessions, product-specific metadata, server-side price verification, verified webhook handling, idempotency controls, and separation between payment confirmation and output generation. A browser redirect or success-page visit alone does not authorize a paid output.

The same Stripe account may support more than one Registry Intelligence product, but compliance applications use their own checkout-session logic and webhook processing so that city-module memberships and unrelated purchases are not changed by a compliance-app transaction.

Users must not send full card numbers, card security codes, online-banking credentials, or payment-account passwords through uploads, support messages, or email. Payment processing is also subject to Stripe’s own security, privacy, availability, and fraud-prevention practices.

10. Retention and deletion

Registry Intelligence distinguishes long-term business records from temporary processing data. Account, invoice, tax, fraud-prevention, consent, transaction, and legal records may be retained for the periods required by applicable law or reasonably necessary to establish, exercise, or defend claims.

Compliance source files, temporary job payloads, intermediate workbooks, and generated packages are not intended for indefinite storage. Each live application must disclose its applicable working, inactivity, download, and deletion windows before or during the upload workflow. Retention may vary because a multi-step workbook process requires a different working period from a one-time calculator.

Automated deletion routines remove expired jobs and associated temporary files according to the active product policy. Operational records necessary to prove payment, deletion, consent, security events, or service delivery may be retained separately without retaining the complete uploaded content.

Deletion from an active system does not always mean immediate removal from every encrypted backup or provider system. Where temporary application content enters a backup, it remains protected, is not restored for ordinary use, and expires through the backup lifecycle unless preservation is legally required. Application designs should avoid placing short-lived customer uploads in long-term backups where reasonably practical.

Users should submit only necessary information and maintain their own authoritative records. Registry Intelligence temporary jobs are not a records-management, evidence-preservation, or archival service.

11. Logging, monitoring, and regulatory integrity

Registry Intelligence maintains operational and security logging appropriate to each Service. Logs may record authentication events, access decisions, status changes, job identifiers, payment references, generation events, download events, source-version checks, administrative changes, errors, rate limits, and suspected abuse.

Logs are designed to support troubleshooting, security review, fraud prevention, integrity verification, incident investigation, and accountability. They should not include raw uploaded files, complete output packages, plaintext passwords, payment-card data, encryption keys, or full authentication tokens.

Compliance applications may monitor official regulatory documents, templates, schemas, and guidance through hashes, version records, snapshots, and structured comparisons. Active and candidate rule versions remain separate. A detected change does not automatically become an active validation rule.

Where a critical rule or source cannot be confirmed as current, the affected application may stop payment or generation. This regulatory freshness gate protects output integrity but does not guarantee that every government change will be detected immediately or interpreted without review.

12. Software, dependencies, and deployment

New application dependencies are installed only inside approved isolated environments after architecture and compatibility review. Application packages and versions are fixed through a dependency manifest or lock file rather than installing unspecified latest versions directly into production.

Security practices may include code review, static analysis, type checking, dependency vulnerability auditing, secret scanning, test coverage, malformed-input testing, property-based testing, webhook verification, authorization testing, and controlled patching.

Development, staging, and production activities are separated according to the product risk. Production data is not used casually for development or testing. Deployment requires defined change scope, rollback planning, backup or recovery readiness, and confirmation that unrelated live products are not modified.

Secrets are not committed to public source code or embedded in WordPress page content. Configuration and credentials are supplied through restricted server-side mechanisms appropriate to the runtime.

13. Testing and release gates

A file-processing or paid-generation application must pass testing proportionate to its risks before production activation. Applicable release gates include:

• authorization and default-deny tests;
• account, role, job-ownership, and cross-user isolation tests;
• malformed, oversized, unsupported, encrypted, and adversarial file tests;
• CSV, XLSX, PDF, XML, archive, encoding, and formula-injection safety tests where relevant;
• output escaping and cross-site scripting tests;
• payment amount, webhook signature, idempotency, replay, and post-payment freshness tests;
• secure-download authorization and expiration tests;
• retention and automated-deletion tests;
• concurrency, resource-limit, failure-recovery, and load tests;
• dependency and configuration review;
• logging checks for secrets, tokens, raw content, and unnecessary technical leakage;
• regression testing to confirm that WordPress, MemberPress, city modules, and unrelated applications remain unaffected.

Passing a test set reduces known risk at a point in time but does not prove that a Service is invulnerable. Security controls and tests are reviewed as software, threats, providers, and product functions change.

14. Backups, recovery, and continuity

Registry Intelligence maintains backup and recovery measures appropriate to core website content, application configuration, databases, regulatory artifacts, and business records. Backup scope, frequency, encryption, retention, and restoration procedures depend on the system and recovery need.

Temporary customer uploads are not treated as the authoritative backup of a user’s business records. Application architecture should exclude short-lived job data from long-term backups where practical, while preserving enough operational evidence to reconcile payment, delivery, deletion, and incidents.

Recovery procedures prioritize restoration of secure operation and integrity. A service may remain unavailable while access controls, credentials, data state, payment events, and rule versions are verified after an incident or restoration.

15. Service providers and data locations

Registry Intelligence relies on selected providers for functions such as hosting, payment processing, email, analytics, accounting, security, and application infrastructure. Providers receive only the information reasonably necessary for their role and are evaluated according to service purpose, access, security, reliability, contractual terms, and data-protection requirements.

Payment processing is performed through Stripe where indicated. Website services may use WordPress, MemberPress, hosting, email, analytics, consent-management, and accounting providers described in the Privacy Policy and Cookie Policy.

Data may be processed in the European Economic Area and in other locations used by approved service providers. Where personal data is transferred outside the EEA, appropriate safeguards are applied as required by applicable data-protection law.

16. Security incidents

Registry Intelligence maintains an incident-response approach designed to identify, contain, investigate, remediate, recover from, and document suspected security events. Depending on the event, actions may include disabling an endpoint, stopping file processing, revoking credentials or download links, rotating secrets, preserving relevant evidence, isolating a service, restoring verified data, or contacting providers.

If an incident affects personal data, payment-related information, user access, or uploaded content, we assess the nature, scope, likely consequences, affected users, and applicable notification duties. Where legally required, we notify the competent authority and affected individuals within the applicable timeframes.

Public disclosure may be delayed where necessary to investigate, contain the event, protect affected users, avoid helping an attacker, comply with law, or coordinate with providers and authorities.

17. User security responsibilities

Security is shared. Users must:

• use a supported, updated browser and operating system;
• protect email, account credentials, devices, networks, and downloaded files;
• use unique strong passwords and multifactor authentication where available;
• verify the polandoc.com domain and HTTPS connection before submitting information;
• upload only supported files and only data necessary for the selected Service;
• avoid uploading passwords, full payment-card data, authentication secrets, or unnecessary sensitive information;
• confirm recipients before forwarding protected links or generated files;
• download output before expiration and store it according to the organization’s own security and retention policy;
• notify Registry Intelligence promptly of suspected unauthorized access, exposed links, incorrect recipients, or security concerns;
• comply with the Terms of Use and applicable law.

18. Vulnerability reporting

Security researchers and users may report a suspected vulnerability to inbox@polandoc.com with the subject line “Security Report.” Include the affected URL or Service, a clear description, reproducible steps, expected and observed behavior, and relevant non-sensitive evidence.

Do not include passwords, complete authentication tokens, payment-card data, or another user’s private content in the initial report. Do not publicly disclose an unresolved vulnerability, access or alter another user’s data, create persistent access, perform denial-of-service testing, use destructive payloads, send malware, or conduct high-volume automated scanning without written authorization.

We will review good-faith reports and may request additional information. Submission does not create a right to payment, reward, employment, public credit, or authorization to exceed applicable law or these restrictions. We ask reporters to allow reasonable time for investigation and remediation before coordinated disclosure.

19. Security references

Registry Intelligence security practices are informed by recognized risk-management, secure-development, file-upload, payment, and data-protection guidance, including:

• NIST Cybersecurity Framework 2.0
• OWASP File Upload Cheat Sheet
• CISA Secure by Design
• Stripe Security Documentation
• General Data Protection Regulation, including Article 32

These references inform control selection. They do not mean that Registry Intelligence, Poland Documents, or every Service is certified, audited, validated, or endorsed by NIST, OWASP, CISA, Stripe, the European Union, or another standards body.

20. Limitations and changes

Security measures reduce risk but cannot eliminate it. The exact controls available may differ across public content, city modules, account services, one-time file tools, and future applications. Product-specific security and retention information presented at upload or purchase supplements this page.

Registry Intelligence may update this page when architecture, providers, file types, products, legal requirements, threats, or safeguards change. A material change to how personal data is processed will also be reflected in the Privacy Policy where required.

This page describes security practices and release standards. It is not a warranty of uninterrupted service, invulnerability, guaranteed recovery, regulatory compliance, or prevention of every unauthorized event. Contractual terms and limitations are provided in the Terms of Use.

21. Security contact

Security questions, suspected unauthorized access, exposed download links, and vulnerability reports may be sent to:

Registry Intelligence / Poland Documents
Email: inbox@polandoc.com
Subject line: Security Report
Business address: Ogrodowa 58/lok. 29, 02-791 Warszawa, Poland
Contact Registry Intelligence