Finducation - EZBudget™
Information Security and Governance Policy
Official document prepared for partner due diligence and Plaid security questionnaire support.
1. Purpose
This policy defines the security and governance framework used to identify, mitigate, and monitor information security risks relevant to EZBudget. It establishes technical and organizational controls used to protect customer data, platform integrity, and service reliability.
2. Scope
This policy applies to the following systems and operations:
- EZBudget web application and mobile wrappers
- Backend API functions and associated service components
- Authentication/session handling and user account services
- Build, release, deployment, and operational monitoring workflows
- Third-party services used for infrastructure and payments (as applicable)
3. Security Governance
3.1 Accountability and Ownership
- Security governance is owned by Deseo Developers LLC engineering leadership.
- Code changes are reviewed through repository controls and tracked change history.
- Security-impacting issues are triaged with priority based on likelihood and business impact.
3.2 Policy and Review Cadence
- This policy is reviewed at least annually and upon material architecture changes.
- Control updates are documented in source-controlled security documentation.
4. Risk Identification and Management
- Security risks are identified through code review, testing controls, and operational observations.
- Risks are classified by severity and remediated based on business and security impact.
- Compensating controls are documented where immediate remediation is not feasible.
5. Technical Security Controls
5.1 Secure Development Controls
- Backend input validation and format constraints are enforced for untrusted payloads.
- Unsafe SQL construction patterns are blocked by automated security guardrails.
- Parameterization and safe data-layer patterns are used for data operations.
5.2 Data and Secrets Protection
- Sensitive secrets and keys are managed server-side; secrets are not embedded in client code.
- Client architecture is designed so sensitive business logic and privileged operations run server-side.
- Access tokens are used for authenticated requests; direct privileged access is restricted.
5.3 Platform Hardening
- Security headers and restrictive browser policies are used to reduce exploitability.
- Production builds apply code protection controls as an additional deterrence layer.
- Changes are deployed through controlled build pipelines with traceable history.
6. Access Control
- Access follows least-privilege principles for systems, code repositories, and service platforms.
- Access is restricted to authorized personnel based on operational role.
- Authentication/session controls are enforced for user-facing protected features.
7. Monitoring and Logging
- Operational logs and error signals are used for troubleshooting and anomaly detection.
- Security-relevant events are reviewed during incident triage and post-incident analysis.
- Build and release outcomes are monitored through deployment platform status signals.
8. Incident Response
- Potential incidents are assessed, contained, and remediated based on severity.
- Root cause and corrective actions are documented following confirmed incidents.
- External notifications are handled in line with contractual and legal obligations.
9. Vendor and Third-Party Oversight
- Third-party processors are selected based on operational/security suitability.
- Data sharing is limited to service-delivery purposes and governed by provider terms.
- Third-party dependencies are reviewed during integration and maintenance cycles.
10. Business Continuity and Change Management
- Application and API changes are versioned and recoverable through source control.
- Deployment processes are repeatable and designed for rapid rollback/recovery when needed.
- Critical updates are prioritized to maintain security and service availability.
11. Training and Awareness
- Engineering personnel follow documented secure coding and data handling standards.
- Security expectations are reinforced through development workflow controls and reviews.
12. Evidence Mapping for Due Diligence
| Control Area | Implementation Evidence (Repository) |
|---|---|
| Security policy baseline | SECURITY.md |
| Secure coding guardrails | scripts/security-check-sql.js and test execution workflow |
| Security architecture and code protection practices | docs/SECURITY_AND_CODE_PROTECTION.md, README_SECURITY.md |
| Plaid integration handlers and server controls | netlify/functions/plaid-handlers.js, api/plaid/*.js |
13. Approval
This document is approved for external due diligence responses as the official Information Security and Governance policy statement for EZBudget.
Approved By: Deseo Developers LLC - Authorized Representative
Date: July 8, 2026
Contact: contact@deseodevelopers.com