Access Controls Policy

Organization: Sierra Digital Forge LLC Product covered: QuiltRBuddy (Windows desktop + Android, .NET MAUI) Effective date: May 18, 2026 Last reviewed: May 18, 2026 Document owner: Ronald Warren, Managing Member Version: 1.0 Related policy: Information Security Policy (Sierra Digital Forge LLC), v1.0

⚠️ DRAFT — REQUIRES LAWYER REVIEW BEFORE PUBLICATION.

1. Purpose

This Access Controls Policy (“Policy”) defines how Sierra Digital Forge LLC (“Sierra Digital Forge”) restricts and governs access to its production assets, sensitive data, and supporting infrastructure. The Policy operationalizes the controls summarized in Section 5 of the Sierra Digital Forge Information Security Policy and adds the procedural depth Sierra Digital Forge’s partners, vendors, and regulators expect.

The objectives of this Policy are:

1. To ensure that every access path to a Sierra Digital Forge production asset or to sensitive data is authenticated, authorized, and traceable.
2. To enforce the principle of least privilege across accounts, API integrations, and physical environments.
3. To establish a documented lifecycle for account provisioning, modification, and deprovisioning.
4. To define the cadence and scope of access reviews.
5. To provide a written reference Sierra Digital Forge can produce on request to partners, vendors, and regulators.

This Policy is operationalized — every commitment described below reflects a practice Sierra Digital Forge currently performs.

2. Scope

This Policy applies to:

• All accounts that provide administrative or operational access to Sierra Digital Forge production assets, including subprocessor dashboards, source-control repositories, code-signing environments, and application distribution channels (Microsoft Store, Google Play Store).
• The developer workstation and any other physical device used to develop, test, sign, release, or operate QuiltRBuddy or any future Sierra Digital Forge product.
• All third-party services and APIs that Sierra Digital Forge consumes on behalf of end users, including Google Cloud (Gemini API), the eventual payment processor ({{PAYMENT_PROCESSOR}}), the Community identity provider ({{IDENTITY_PROVIDER}}), the Google Play Console, and the Microsoft Partner Center.
• All access to sensitive data as classified in Section 4 of the Sierra Digital Forge Information Security Policy.

This Policy does NOT cover:

• End-user authentication on the user’s own Windows or Android device. End users authenticate locally; Sierra Digital Forge does not control device-level access.
• Subprocessor-internal personnel access. Each subprocessor maintains its own access management for its employees and infrastructure.

3. Definitions

4. Roles & Responsibilities

Sierra Digital Forge is a member-managed limited liability company. All access management roles are currently vested in the Managing Member.

5. Account Lifecycle Management

5.1 Account types

Sierra Digital Forge maintains three categories of accounts:

5.2 Provisioning

New accounts are provisioned by the Managing Member as follows:

1. Verify need. Confirm that a new account is required for a specific feature or operation, and that no existing account can satisfy the need under the principle of least privilege.
2. Create with minimum scope. Provision the account at the lowest privilege tier the vendor offers, and with the smallest set of products/permissions required.
3. Enable MFA. Two-factor authentication is enabled on the new account before the account is used for any operation.
4. Store credentials. Username and password are entered in the Sierra Digital Forge password manager.
5. Record. The account is added to the internal access register described in Section 14.

5.3 Modification

When an account’s role, privilege scope, or owner changes:

1. The Managing Member evaluates whether the change is the minimum modification required.
2. The change is applied via the relevant vendor dashboard.
3. The change and its justification are recorded in the access register.
4. If the modification removes privilege, it takes effect immediately. If it adds privilege, it is reviewed against this Policy before approval.

5.4 Deprovisioning

When an account is no longer needed:

1. The account is disabled or deleted via the vendor dashboard within 30 days of the trigger event, or sooner if the account holds production-relevant access.
2. The corresponding credential entry in the password manager is moved to an archived section and the underlying credential is rotated by the vendor or invalidated.
3. The access register is updated with the deprovisioning date and reason.

5.5 Credential rotation

Service / build credentials are rotated:

• Annually, as part of the policy review cadence described in Section 14.
• Immediately on suspected compromise. See the Incident Response procedure in Section 8 of the Information Security Policy.
• Promptly when a credential’s scope is reduced.

6. Authentication

6.1 Multi-factor authentication

Two-factor authentication is required on every account that meets any of the following criteria:

• Provides administrative access to a Sierra Digital Forge production asset.
• Provides access to a subprocessor dashboard that holds or controls Sierra Digital Forge customer integrations.
• Provides access to source code, code-signing keys, or build artifacts.
• Provides access to the password manager.

Accounts that currently enforce 2FA include, without limitation:

• Google Cloud Console (Gemini API project)
• {{PAYMENT_PROCESSOR}} administrative dashboard
• {{IDENTITY_PROVIDER}} administrative dashboard
• Microsoft Partner Center
• Google Play Console
• GitHub (private repository hosting QuiltRBuddy source)
• Personal password manager
• Developer workstation OS account (sign-in protected by strong password; biometric or PIN unlock layered on top where supported by Windows Hello)

No production-relevant account is exempt from 2FA. No shared administrative accounts are used.

6.2 Password requirements

Passwords used on Sierra Digital Forge administrative and subprocessor accounts meet the following minimum standards:

• 16 characters or longer.
• Mix of uppercase, lowercase, numbers, and symbols, unless the service does not accept symbols.
• Generated by the password manager’s random-password generator.
• Unique per service.
• The password manager’s master password is at least 20 characters, randomly generated, memorized by the Managing Member, and never stored in plaintext anywhere outside the Managing Member’s memory.

6.3 Credential storage

• Administrative and subprocessor account passwords are stored exclusively in the password manager, encrypted at rest with a master-key-derived AES-256 key.
• Service / build credentials required at compile time (GEMINI_API_KEY, payment-processor keys) are stored in secrets.json or an equivalent local configuration file on the developer workstation. This file is listed in .gitignore and is not synchronized to any cloud service.
• Production credentials are never embedded in source code committed to version control.
• Production credentials are never transmitted by email, chat, or any unencrypted channel.

6.4 Session management

• Subprocessor dashboards use the vendor’s default session-expiration settings.
• The developer workstation locks automatically after a short idle period and on lid close.

7. Authorization & Least Privilege

7.1 Principle

Every account, API key, and integration operates at the minimum privilege required to perform its intended function.

7.2 Subprocessor product scoping

7.3 API key scoping

Where a subprocessor supports differentiated keys by environment (sandbox / production), Sierra Digital Forge maintains separate keys for each environment. Sandbox and production keys are not interchangeable in either direction. Stripe-style publishable keys vs. secret keys are differentiated: publishable keys may appear in client-side code; secret keys never do.

7.4 Repository access

The source-code repository hosting QuiltRBuddy is configured as a private GitHub repository owned by the Managing Member. Read and write access are limited to the Managing Member. No collaborators, integrations, or third-party apps are granted access without an explicit business justification and an entry in the access register.

8. Privileged Access Management

Because Sierra Digital Forge currently operates with a sole authorized operator, all privileged access resides with the Managing Member. The following controls apply:

• No separation of duty between owner and operator. This limitation is documented and reviewed.
• No standing privilege beyond what is operationally required. Subprocessor dashboards default to read-only views; elevated actions (e.g., rotating a payment-processor secret) are performed deliberately and recorded.
• Privileged actions are logged. Subprocessor dashboards generate audit trails on the vendor side. The developer workstation generates standard Microsoft Windows audit logs.
• Code-signing keys for QuiltRBuddy are held in the developer workstation’s local keystore (Windows: per-store signing cert in the user certificate store; Android: per-app upload keystore plus optional Play App Signing managed by Google). The Android upload keystore file itself is backed up offline. No cloud-hosted code-signing service is used.

9. Physical Access Controls

9.1 Developer workstation

• Location. A private office located within Nevada, USA. The office is inside a private residence and is not accessible to the general public. The specific street address is withheld from this published policy for security reasons; service of process and partner correspondence should be directed to the registered-agent address in the Distribution & Contact section.
• Operating system. Microsoft Windows with the latest stable security patches applied.
• Full-disk encryption. BitLocker is enabled on the system drive and on the working data drive (D:\Projects\QuiltRBuddy). The BitLocker recovery key is stored in the password manager and offline in a separate secure location.
• Account password. The Windows account requires a strong password to sign in. Windows Hello (PIN or biometric) is enabled as the day-to-day unlock factor.
• Idle lock. The workstation locks automatically after a short idle period and on lid close.
• No cloud synchronization of project secrets. The project working directory is excluded from OneDrive synchronization to prevent inadvertent replication of secrets.json or other secret-bearing files to cloud storage.

9.2 Mobile test devices

Mobile test devices used to validate the QuiltRBuddy Android application are configured with:

• Device-level encryption (Android default on modern devices).
• A PIN, password, or biometric unlock.
• Auto-lock on idle.

Test devices do not store production user data; they store sandbox test data only, which is wiped when the test cycle completes.

9.3 Physical premises

The home office is locked when unattended.

10. Remote Access

Sierra Digital Forge does not currently operate a remote-access infrastructure (VPN, jump host, bastion server). The Managing Member accesses subprocessor dashboards directly from the developer workstation over HTTPS, authenticated with 2FA. There is no remote-administration channel into the developer workstation itself; the workstation does not accept inbound remote sessions.

11. Production Environment Access

Sierra Digital Forge’s production environment consists of:

• The Community identity provider ({{IDENTITY_PROVIDER}}), administered by the Managing Member through the provider’s console with 2FA.
• The payment processor ({{PAYMENT_PROCESSOR}}), administered by the Managing Member through the processor’s dashboard with 2FA.
• The Gemini project in Google Cloud Console.
• The Microsoft Partner Center and Google Play Console.
• The source-code repository.
• The developer workstation.

Production-environment access controls therefore reduce to dashboard, console, repository, and workstation controls — each of which is covered in the preceding Sections.

12. End-User Data Access

Sierra Digital Forge personnel access to user data is limited to Community-backend administrators (the Managing Member) and is governed by:

• Per-user authorization rules at the identity-provider tier.
• Audit logging of every administrative access on the vendor side.
• The principle that administrative access is performed only for legitimate operational reasons (documented support request, confirmed incident, regulatory compliance request) and recorded as such.

Routine end-user activity does not surface to Sierra Digital Forge personnel. The App does not provide a support-tier mechanism, customer-service backdoor, or telemetry pipeline that allows Sierra Digital Forge personnel to view, modify, or extract a user’s stored data outside the administrative path described above.

User-initiated deletion (in-app via Edit > Preferences > Your Data > Delete Community Account, or by email at privacy@) is the path by which Sierra Digital Forge interacts with the user’s data for deletion purposes.

13. Third-Party / Subprocessor Access

The current Sierra Digital Forge subprocessor list and the data each subprocessor receives are documented in Section 7 of the Information Security Policy. The access-management commitments specific to subprocessors are:

• Onboarding. Each subprocessor is evaluated for its security posture and contractual data-protection commitments before integration.
• Account management. Each subprocessor account is held by the Managing Member, protected by 2FA, and scoped to the minimum products required.
• Monitoring. Subprocessor security advisories and status notifications are routed to info@sierradigitalforge.com.
• Offboarding. When a subprocessor is removed, the relevant API keys are revoked, the corresponding code path is removed or feature-flagged off, and any locally cached tokens for the removed subprocessor are deleted from user devices in the same release.

14. Access Reviews

14.1 Scheduled reviews

The Managing Member performs an access review at least once per calendar year. The review covers:

1. Account inventory. Confirm every administrative and subprocessor account is still required.
2. Privilege review. Confirm each account is still at the minimum privilege tier required for its function.
3. MFA verification. Confirm 2FA remains enabled on every in-scope account.
4. Credential rotation. Rotate service / build credentials as described in Section 5.5.
5. Subprocessor product scope. Confirm each subprocessor’s product scope is still the minimum required.
6. Recovery information. Verify password manager recovery, BitLocker recovery key location, code-signing keystore backup, and ownership-transfer plans are current.

The review is documented with a date, summary findings, and remediation actions. Reviews are retained as part of the Sierra Digital Forge security record.

14.2 Triggered reviews

An access review is also performed promptly upon:

• A personnel change (joiner, mover, leaver).
• A vendor change.
• A confirmed security incident affecting any in-scope account.
• A suspected credential compromise.
• A material architectural change that introduces new access paths.

14.3 Access register

Sierra Digital Forge maintains a simple access register listing each in-scope account with: service name, account purpose, owner, 2FA status, creation date, last-reviewed date.

15. Exception Process

If an operational situation appears to require a deviation from this Policy:

1. The exception is documented in writing before it is implemented.
2. The exception is approved by the Managing Member.
3. The exception is logged with start and end timestamps.
4. The exception is reviewed and closed promptly when the underlying need ends.

No exception has been issued since the effective date of this Policy.

16. Enforcement & Sanctions

Violations of this Policy by Sierra Digital Forge personnel may result in immediate revocation of relevant access, mandatory corrective action, and (for material violations) termination of the personnel relationship.

17. Related Documents

• Sierra Digital Forge Information Security Policy (v1.0)
• Sierra Digital Forge Privacy Policy (published at the URL specified in the Google Play Console listing for QuiltRBuddy)
• Google Play Developer Distribution Agreement and Data Safety form
• Microsoft Store policies and developer agreements
• Subprocessor Terms of Service for Google Cloud, the payment processor, and the Community identity provider

18. Distribution & Contact

This Policy is made available to partners, vendors, and regulators on request.

Sierra Digital Forge LLC — primary contacts

19. Acknowledgment

I, Ronald Warren, in my capacity as Managing Member of Sierra Digital Forge LLC, attest that the access controls described in this Policy are operational as of the Effective Date.

Ronald Warren Managing Member, Sierra Digital Forge LLC Date: May 18, 2026