Access Control Policy
Budgetfold · Version 1.0 · Effective September 22, 2026 · Reviewed at least annually · Supplements the Information Security Policy
1. Purpose and scope
This policy defines who may access Budgetfold production systems and user data, how that access is granted, verified, reviewed, and removed. It covers all production assets: the Google Cloud / Firebase project (Firestore, Cloud Functions, Secret Manager, Hosting), the Plaid dashboard and API, Apple App Store Connect, and the source code repository. It also defines how end users are authorized inside the app.
2. Principles
- Least privilege. Every person, service, and end user gets the minimum access needed for their role.
- Unique identity. No shared accounts. Every action is attributable to a named person or a named service account.
- Multi-factor authentication is required on every administrative account.
- Deny by default. Data is unreachable unless a rule explicitly allows it.
3. Roles and responsibilities
| Role | Who | Access |
|---|---|---|
| Security owner / administrator | Dean Gergoric (Founder and Developer) | Owner of the Google Cloud project, Plaid account holder, App Store Connect Account Holder, repository owner. Sole person with production access. |
| Service accounts | Cloud Functions runtime identity | Firestore read/write and Secret Manager accessor for the Plaid secrets only. Authenticates with short-lived Google OAuth tokens; no long-lived keys are issued or downloaded. |
| End users | Budgetfold account holders | Only their own profile and the budgets they belong to, as owner or editor (section 6). |
There are currently no other employees or contractors. If any are added, they receive a named account, the minimum IAM role for their task, and are recorded in an access register before access is granted.
4. Administrative access
- Google Cloud / Firebase: access is managed through Google Cloud IAM. The administrator signs in with a Google account protected by two-step verification.
- Plaid dashboard: individual login with multi-factor authentication enabled. API access uses the client ID and environment secret stored only in Google Secret Manager.
- App Store Connect: individual Apple ID with two-factor authentication.
- Source code: private Git repository; pushes require an authenticated account with two-factor authentication.
- Administrative sessions occur only from the administrator's own encrypted, passcode-protected devices with automatic screen lock.
5. Non-human access and secrets
- Cloud Functions authenticate to Google services with the runtime service account's OAuth tokens. No service-account key files exist.
- Plaid credentials are stored in Google Secret Manager and injected into functions at runtime. They never appear in source control, build logs, or the mobile app.
- Plaid access tokens are stored server-side in a Firestore collection that no client identity can read or write; only the functions' service account can.
- Secrets are rotated at least annually and immediately on suspected exposure.
6. End-user access model
- Users authenticate with Firebase Authentication using Sign in with Apple, Google Sign-In, or email and password.
- Authorization is enforced by Firestore security rules on every read and write:
- A user can read a budget only if their user ID is in that budget's member list.
- Budget owners may manage members, categories, invite codes, and delete the budget. Editors may add and edit entries but cannot manage members.
- Joining a budget requires a valid, unexpired invite code, validated by the rules on the server.
- Bank-link records visible to the app are per user and readable only by that user. Access tokens and subscription entitlements are never readable by clients.
- Before a bank connection can be started, the app requires a device biometric check (Face ID or Touch ID, with device passcode as fallback), and the server verifies the user's budget membership and active subscription before issuing a Plaid Link token.
- Users can remove their own access at any time by leaving a budget, unlinking a bank, or deleting their account.
7. Provisioning and de-provisioning
- New administrative access is granted only by the security owner, recorded with the date, role, and reason.
- Access is removed on the day a person's role ends. For Google Cloud this is done by removing the IAM binding; for Plaid and App Store Connect by removing the user in the respective dashboard.
- Because all administrative systems use centralized identity (Google Cloud IAM, Apple ID, Plaid team management), removal takes effect immediately across the system.
8. Access reviews
- At least annually, and after any significant change, the security owner reviews: IAM members and roles on the Google Cloud project, Plaid dashboard team members, App Store Connect users, repository collaborators, and the Firestore security rules.
- Review results and any changes are recorded in the project repository.
9. Logging
- Google Cloud audit logs record administrative actions on the project. Cloud Functions logs record each Plaid operation by user ID without secrets or tokens.
- Firebase Authentication records sign-in events. Logs are retained for at least 30 days and reviewed when investigating anomalies.
10. Exceptions
Any exception to this policy must be approved in writing by the security owner, time-limited, and reviewed at the next access review.
Contact: Dean Gergoric, Founder and Developer, dgergoric2@gmail.com