Information Security Policy

How DerMar Consulting Group LLC (dba "ForgeWorks") identifies, mitigates, and monitors information security risks across its products and infrastructure.

Version 1.0 · Effective June 29, 2026 · Reviewed at least annually

1. Purpose and scope

This policy describes how ForgeWorks identifies, mitigates, and monitors information security risks across the software products it operates (including LedgerForge, RunSheet, FieldForge, RemediDocs, and related services) and the supporting infrastructure. It applies to all systems that store or process customer data, all third-party services used to deliver those products, and anyone with access to production systems.

ForgeWorks is a small, owner-operated software company. This policy is sized to that reality: it documents controls that are actually implemented and operated, not controls that require a dedicated security team. Where a practice is in progress rather than fully operationalized, it is labeled as such.

2. Roles and responsibilities

• Security owner. The Founder is responsible for information security: setting this policy, granting and revoking access, reviewing logs, applying patches, and handling incidents. There is no separate security team; security duties are an explicit, named responsibility of the Founder.
• Contractors and collaborators, if any, receive only the access required for their work and are bound by the same handling rules. Access is removed when their work ends.
• The security contact for vendors, auditors, and partners is info@getforgeworks.com, a monitored address.

3. Data inventory and classification

ForgeWorks classifies the data it handles into three tiers:

• Secrets (highest sensitivity): API keys, OAuth/access tokens, database credentials, signing keys. Stored encrypted or in restricted-permission files, never in source control, never returned to clients.
• Customer data: account records, application data the customer creates (bills, routes, reports), and, where a product connects to a bank, transaction and balance data retrieved through Plaid.
• Operational data: application logs, audit logs, and error logs used to run and debug the services.

ForgeWorks does not store bank login credentials. Bank authentication is handled entirely by Plaid; ForgeWorks receives only a Plaid access token (encrypted at rest) and the financial data the user authorizes. ForgeWorks does not store full payment card numbers; card payments are processed by Stripe.

4. Access control and authentication

• End-user authentication uses signed JSON Web Tokens (HS256). Passwords are hashed with bcrypt and are never stored or logged in plaintext.
• The application signing key is required to be a strong, non-default value; the service refuses to start with an empty or placeholder secret.
• Least privilege. Each integration requests only the scopes it needs (for example, the bank-sync integration requests read-only transaction and balance access, not payment-initiation or account-ownership scopes). Administrative actions are gated behind role checks.
• Multi-tenant isolation. Every product is multi-tenant. Every database query that touches tenant-owned data is filtered by the tenant identifier so that one customer cannot read or modify another customer's data. Referenced foreign keys are validated against the caller's tenant before use.

5. Encryption

• In transit. All customer-facing traffic is served over HTTPS/TLS. Certificates are issued and renewed automatically through the reverse proxy (Caddy with Let's Encrypt).
• At rest. High-sensitivity secrets such as Plaid access tokens are encrypted before they are stored in the database, using authenticated symmetric encryption (Fernet/AES). Encryption keys are not committed to source control. Database storage resides on the operator's controlled infrastructure.

6. Secrets management

• Production secrets are kept in restricted-permission files outside the application source tree and injected into services at runtime as environment variables. They are not committed to version control.
• Secrets are never written to logs or returned in API responses.
• Provider secrets (Plaid, Stripe, and similar) are stored separately per service and rotated if a compromise is suspected.

7. Third-party and vendor management

ForgeWorks relies on a small set of established service providers and limits the data shared with each to what the feature requires:

• Plaid — bank account connectivity. Provides read-only access to transactions and balances after the user explicitly authorizes the connection. Plaid is the system of record for the user's bank credentials; ForgeWorks never sees them.
• Stripe — subscription billing and payment processing. Stripe handles card data; ForgeWorks does not store card numbers.
• Hosting and infrastructure — production services run in isolated containers on a virtual private server hosted by an established cloud provider (Hetzner), behind a TLS-terminating reverse proxy (Caddy), with DNS and edge protection managed through Cloudflare. Each product runs with its own database on its own container network.

New vendors are reviewed for their security posture and data handling before integration, and only the minimum necessary data is shared.

8. Secure development practices

• Source code is version controlled. Changes are developed and verified in a staging environment before promotion to production.
• Database schema changes run through a tracked, ordered, idempotent migration system, so production schema changes are deliberate and repeatable.
• Common web vulnerabilities are addressed as a baseline: parameterized database access through an ORM (mitigating SQL injection), tenant-scoped authorization on every record access (mitigating insecure direct object references), framework-handled output, and path-traversal protection on file-serving routes.
• Dependencies are pinned to specific versions and updated when security fixes are released.

9. Logging and monitoring

• Each request is assigned a request identifier and recorded in a structured access log.
• Unhandled errors are captured to an error log with type, message, and traceback for diagnosis.
• Significant tenant actions are recorded in an audit log.
• Logs are reviewed when investigating issues and after any suspected security event, and are written so as not to contain secrets or full payment data.

10. Rate limiting and abuse prevention

Authentication-sensitive and high-cost endpoints are rate limited to reduce credential-stuffing and abuse. Edge protection (Cloudflare) provides an additional layer in front of the origin.

11. Vulnerability and patch management

• Base images and dependencies are updated on a regular basis and promptly when a relevant security advisory is published.
• The Founder monitors advisories for the core frameworks and providers in use and applies fixes through the normal staging-to-production process.

12. Backup and recovery

• Production databases are backed up on a regular schedule, and backup/restore procedures are exercised so data can be recovered after loss or corruption.
• Recovery steps are documented as part of operational runbooks.

13. Incident response

If a security incident is suspected:

1. Contain — revoke or rotate the affected credentials and, if necessary, take the affected service offline.
2. Assess — use access, audit, and error logs to determine what data and which tenants were affected.
3. Remediate — fix the underlying issue, deploy through staging to production, and confirm closure.
4. Notify — inform affected customers and any required parties (including providers such as Plaid or Stripe where their data or integration is involved) without undue delay, consistent with applicable law and provider agreements.
5. Review — record the incident and corrective actions, and update this policy or the controls if needed.

The security contact for incident reports is info@getforgeworks.com.

14. Data retention, privacy, and deletion

• ForgeWorks collects and retains only the data needed to provide each product.
• Customers can delete their data; account deletion removes the customer's records, and connected third-party items (for example, a Plaid connection) are removed through the provider's API so data retrieval stops.
• Products that operate on platforms with mandatory compliance hooks (for example, Shopify's customers/data_request, customers/redact, and shop/redact webhooks) implement those hooks to honor data access and deletion requests.
• Personal data is not sold or shared with third parties except the service providers required to deliver the product, as described in each product's Privacy Policy.

15. Risk management process

ForgeWorks manages information security risk as an ongoing cycle:

• Identify — maintain the data inventory in Section 3, and review where sensitive data flows when features or vendors change.
• Mitigate — apply the controls in this policy (least privilege, tenant isolation, encryption, secrets handling, rate limiting, secure development) proportionate to the sensitivity of the data.
• Monitor — review logs and provider dashboards, watch for anomalies and security advisories, and respond to incidents per Section 13.

This process is owned by the Founder and revisited at the review cadence above and whenever a material change occurs.

16. Physical and endpoint security

Production runs in a reputable cloud data center rather than on premises. Servers are administered remotely over encrypted, key-based SSH (password login disabled), and administrative access is restricted to the operator. Administrative systems are kept patched.

17. Policy review and revision history

This policy is reviewed at least annually and after any material system change or security incident.

Version	Date	Change
1.0	2026-06-29	Initial policy issued