← Material Systems

Information Security Policy

Organization: Material Systems LLC  ·  Version: 1.0  ·  Effective: July 9, 2026  ·  Last reviewed: July 9, 2026  ·  Next review: July 2027

Material Systems LLC (“Material Systems,” “we,” “us”) maintains a documented, operational information security program to identify, mitigate, and monitor the information security risks relevant to our business. This policy describes that program: the controls we apply to protect the confidentiality, integrity, and availability of the information entrusted to us — including customer data, financial account information, and the systems that process it — and how we keep those controls current as our products evolve.

1. Purpose & commitment

The purpose of this policy is to establish and communicate Material Systems' commitment to protecting information assets against unauthorized access, disclosure, alteration, and destruction. Information security is treated as a continuous program — a set of controls and procedures that are operationalized, monitored, and matured over time — not a one-time exercise. All personnel and contractors who access Material Systems systems or data are required to understand and comply with this policy.

2. Scope

This policy applies to:

• All information systems, applications, source code, cloud infrastructure, and data owned or operated by Material Systems that store, process, or transmit customer, financial, or company data — including our software products and their supporting services.
• All personnel, contractors, and other authorized parties who access those systems or data.
• All third-party service providers (subprocessors) engaged to store or process data on our behalf.

The controls below are applied in proportion to the sensitivity of the data and the risk to the business. Customer financial data and third-party financial account data (such as data accessed through Plaid) receive the highest level of protection.

3. Governance & responsibility

Accountability for information security rests with Material Systems' management. A designated Security Officer — a role held by a company principal — owns the security program and is responsible for:

• Maintaining and approving this policy and the supporting procedures.
• Reviewing security risks and control effectiveness on a recurring basis.
• Making risk-acceptance and remediation decisions.
• Coordinating the response to any security incident.

Because Material Systems is a small organization, responsibilities are held by a limited number of trusted individuals; this concentration is offset by the use of managed, security-hardened cloud platforms, least-privilege access, and automated controls described throughout this document. Every person with access to production systems is bound by confidentiality obligations.

4. Risk management

We take a risk-based approach to security. On at least an annual basis, and whenever a significant change is made to our products, infrastructure, or data-handling (for example, integrating a new financial data provider), we:

• Identify the assets and data involved and the threats to them.
• Assess the likelihood and impact of those threats.
• Select, implement, and verify controls to reduce risk to an acceptable level.
• Document accepted residual risks and revisit them at the next review.

Findings from monitoring, dependency scanning, code review, and any incidents feed back into this process so the program matures continuously.

5. Access control & authentication

• Least privilege. Access to systems, data, and administrative consoles is granted only as needed to perform a role, and is reviewed periodically. Broad or standing administrative access is minimized.
• Unique accounts. Individuals use their own named accounts; shared credentials are avoided. Access to production data is restricted to authorized personnel.
• Multi-factor authentication (MFA). MFA is required on all administrative, source-control, cloud-infrastructure, and payment/financial-provider accounts that support it (including source control, hosting, database, payment, and email platforms).
• Strong authentication for customers. End-user authentication to our applications uses a managed identity provider supporting passwordless email sign-in and OAuth; we do not store customer passwords ourselves.
• Tenant isolation. In multi-tenant applications, every data-access path is scoped to the authenticated tenant in the application's service layer, backstopped by database row-level security policies, so one customer cannot access another customer's data.
• Onboarding & offboarding. Access is provisioned when a role begins and promptly revoked when it ends or is no longer required.

6. Data classification & protection

We classify data to ensure it is handled appropriately:

Secrets are never stored in the application database or in source control. Sensitive customer files (such as uploaded receipts) are stored in private object storage and served only through short-lived, signed URLs.

7. Encryption

• In transit. All network communication with our applications and between our services and third-party providers is encrypted using TLS (HTTPS). Plain-text transport of sensitive data is not permitted.
• At rest. Production databases, object storage, and backups are encrypted at rest by our cloud providers using industry-standard algorithms (AES-256 or equivalent). Restricted data such as third-party financial access tokens is protected as a secret and encrypted at rest.
• Key management. Encryption keys are managed by our cloud platforms' managed key services; application secrets are held in encrypted environment configuration, not in code or the database.

8. Secrets & credential management

API keys, database credentials, signing secrets, and financial-provider tokens are treated as Restricted data. They are stored only in the hosting platform's encrypted environment/secret store, are never committed to source control (enforced by convention and review), and are never written to the application database or client-side code. Secrets are rotated when a compromise is suspected and when personnel with access change.

9. Infrastructure & network security

Material Systems does not operate its own physical servers or data centers. Production workloads run on established managed cloud platforms whose providers maintain recognized security certifications (such as SOC 2 and ISO 27001) and provide physical security, network isolation, DDoS protection, and platform patching. Our responsibilities focus on secure configuration, access control, and application-level security. Additional network-layer controls include:

• All application endpoints served exclusively over HTTPS.
• Verification of the authenticity of inbound webhooks using cryptographic signatures before any action is taken.
• Rate limiting and idempotency controls on sensitive endpoints to resist abuse and replay.
• Segregation of production credentials and data from development and test environments; development and automated testing use isolated, non-production data.

10. Secure software development

Security is built into how we build software:

• Version control & change management. All code is maintained in version control with a full history. Changes are made on branches and reviewed before being merged to the main line.
• Code review. Changes are reviewed for correctness and security, including additional adversarial review for higher-risk areas such as payments and data-access boundaries.
• Automated quality gates. Type checking, linting, and an automated test suite run against changes; security-relevant behaviors (tenant isolation, idempotency, webhook verification, atomic financial writes) are covered by tests.
• Dependency management. Third-party dependencies are pinned and updated in response to security advisories.
• Least-data design. Applications are designed to collect and retain only the data needed to provide their features, and to keep sensitive processing on the server rather than the client.

11. Endpoint & asset security

Workstations used to access production systems and source code are kept up to date with vendor security patches, run full-disk encryption, are protected by strong authentication and automatic screen lock, and use reputable operating-system security protections. Access to production systems from endpoints requires the same MFA-protected accounts described above.

12. Logging, monitoring & auditing

• Application and infrastructure events are logged. Structured application logs capture errors and significant events to support detection and investigation.
• Security-relevant actions within our applications are recorded in an append-only audit trail scoped to each tenant.
• Cloud platforms provide access and activity logging for infrastructure, database, and administrative consoles.
• Logs are monitored for errors and anomalies, and are used during incident investigation. Sensitive values (secrets, tokens, full financial credentials) are excluded from logs.

13. Vulnerability & patch management

Managed platform components (operating systems, databases, runtimes) are patched by our cloud providers. At the application layer, we monitor dependency security advisories and apply updates on a risk-prioritized basis, expediting fixes for high-severity issues. Security is re-evaluated when significant changes are introduced. We welcome good-faith vulnerability reports at the contact address below and will investigate and remediate confirmed issues.

14. Third-party & vendor risk

We rely on a small set of reputable subprocessors to operate our services. Before engaging a provider that will handle Restricted or Confidential data, we evaluate its security posture and certifications and prefer providers that maintain recognized attestations (such as SOC 2). Representative categories and providers include:

We share with subprocessors only the data necessary for them to perform their function, and we do not sell customer or financial data. Payment card data is handled by our PCI-compliant payment processor and does not touch our servers.

15. Handling of financial account data (Plaid)

Where our products connect to a customer's financial accounts through Plaid, we handle that data with particular care:

• Authorization. Financial accounts are connected only when the customer explicitly authorizes the connection through Plaid's secure flow. We do not ask customers for, or store, their online banking usernames and passwords — those are handled entirely by Plaid.
• Least scope. We request only the Plaid products and data fields required to provide the feature the customer has chosen.
• Token protection. Plaid access tokens and item identifiers are classified as Restricted data: encrypted at rest, access-restricted, kept out of logs and client-side code, and never shared with unauthorized parties.
• Purpose limitation. Financial account data is used solely to provide the requested functionality to the authorizing customer. It is not sold, and it is not used for advertising.
• Revocation & deletion. Customers can disconnect a linked financial institution; on disconnection or account deletion, we revoke the associated Plaid access and delete or disassociate the related data in accordance with our retention practices.
• Compliance. Our use of Plaid is governed by, and conducted in accordance with, the Plaid Developer Policy and applicable law.

16. Incident response & breach notification

We maintain an incident response procedure so that suspected or confirmed security incidents are handled promptly and consistently:

• Detect & report. Anyone who suspects an incident reports it immediately to the Security Officer.
• Contain & assess. We act to contain the issue (for example, rotating credentials, revoking access, or disabling an affected component) and assess its scope and impact, including what data may have been affected.
• Remediate. We remediate the root cause and restore normal operation.
• Notify. We notify affected customers, and relevant providers (including Plaid) and authorities, as required by applicable law and our contractual obligations, without undue delay.
• Learn. After significant incidents we conduct a review and update controls to prevent recurrence.

17. Business continuity, backup & recovery

Customer data in production databases is backed up by our managed database platform, which provides automated backups and point-in-time recovery. Source code and infrastructure configuration are version-controlled and reproducible. Because our infrastructure is managed and defined as code, services can be restored on the provider's platform in the event of disruption. Recovery procedures are validated as part of periodic review.

18. Physical & remote-work security

Physical security of servers and data is provided by our cloud infrastructure providers at their certified data centers. Material Systems personnel work remotely; endpoint controls (full-disk encryption, patching, screen lock, strong authentication) protect data accessed from work devices, and personnel are responsible for the physical security of those devices.

19. Personnel security & awareness

Access to systems and data is limited to a small number of trusted individuals. All personnel and contractors with access are bound by confidentiality obligations, are granted access on a least-privilege basis, and are expected to follow this policy and secure-handling practices for sensitive data. Access is reviewed and revoked when a person's role changes or ends. Security expectations are communicated as part of engagement and reinforced as the program matures.

20. Data retention & disposal

We retain customer and financial data only as long as needed to provide the service and to meet legal, tax, and regulatory obligations. Customers can request deletion of their data. When data is no longer needed, it is deleted or de-identified; managed-platform storage and backups are disposed of securely by the provider in the ordinary course. Financial access tokens are revoked and removed when a connection is disconnected or an account is closed.

21. Compliance

Material Systems operates in compliance with applicable laws and regulations governing the data we handle, and with the contractual and program requirements of the providers we integrate with (including Plaid and our payment processor). Payment card processing is delegated to a PCI DSS-compliant provider. We do not currently hold a SOC 2 or ISO 27001 certification; our program is built on the same control domains those frameworks describe and on the certified infrastructure of our subprocessors, and we intend to mature it further as the business grows.

22. Policy maintenance & review

This policy is reviewed and approved at least annually, and updated whenever there is a significant change to our systems, data handling, or risk profile — for example, adding a new subprocessor or data source. Updated versions are published at this URL with a new version number and review date. The version history is recorded below.

23. Contact

Questions about this policy, or reports of a suspected security issue, can be sent to info@materialsystems.io.