Security & Privacy Position

Future Built Digital is a technical agency and systems consultancy, not a managed-security or cybersecurity-audit firm. Security is nevertheless a baseline engineering responsibility in the systems we build and operate.

This page describes our default security and privacy posture. It is not a certification, audit report, penetration-test result, or promise that every control applies identically to every project.

1. Core principles

Minimize what we collect

We prefer to collect and retain only information that serves a real business or system purpose.

Keep ownership explicit

Every system should identify which application or service owns authoritative state, who can access it, and how copied/integrated data is handled.

Least privilege

People, service accounts, APIs, and automation should have only the access reasonably needed to perform their role.

Protect secrets

Credentials, API keys, private keys, and other secrets should not be committed to source control or exposed to client-side code.

Validate at trust boundaries

User input, external payloads, model output, and integration data should be treated as untrusted until handled appropriately.

Design failure behavior

Important workflows should define what happens when an API, model, webhook, job, or downstream system fails. Silent data loss is not an acceptable recovery strategy.

Make important behavior observable

Production systems should provide enough logging, monitoring, or tracing to answer whether important work executed, failed, retried, or requires human attention.

2. Typical application safeguards

Depending on the architecture and risk profile, Future Built commonly applies controls such as:

• server-side authentication and authorization;
• row-level security where appropriate;
• role-based or least-privilege access;
• input and schema validation;
• secure secret/configuration handling;
• rate limiting and abuse controls;
• content-security policies and secure headers where appropriate;
• environment separation;
• dependency and vulnerability review;
• protected administrative operations;
• idempotency and retry rules for external side effects;
• audit/event history for consequential workflows;
• backups and recovery planning where Future Built operates persistent state;
• structured logging and alerting;
• explicit human-review states for consequential automation;
• data-minimization rules for analytics and telemetry.

The exact controls depend on the system.

3. Project Brief security

The public Start a Project flow is intended for ordinary business and project information.

The design should:

• validate submissions server-side;
• rate-limit abuse;
• use anti-spam controls appropriate to actual traffic;
• avoid sending email, phone, company name, or freeform Project Brief text to analytics;
• keep email/phone out of the AI summarization payload;
• escape submitted text before email rendering;
• store normalized answers separately from the AI summary;
• preserve the prospect-approved final summary;
• allow submission even if the AI component is unavailable.

The Project Brief should not be used for passwords, credentials, financial-account details, health information, government identifiers, or other highly sensitive material.

4. Client environments

Where practical, Future Built prefers client-controlled or clearly assigned production accounts for services that become part of the client's ongoing system.

Access should be limited to the people and services that need it.

At handoff or termination, the project agreement should define:

• account/control transfer;
• credential rotation where appropriate;
• removal of Future Built access;
• source-code and documentation delivery;
• retained operational records;
• any ongoing support access.

5. Service providers

Modern systems depend on hosting, cloud, database, email, AI, analytics, source-control, and other providers.

We evaluate providers according to project needs rather than promising one universal stack.

For systems that handle confidential or personal data, material considerations may include:

• authentication and access controls;
• encryption capabilities;
• backup/recovery;
• provider retention;
• model-training terms where AI is involved;
• logging and auditability;
• data location;
• subprocessor posture;
• breach/incident terms;
• contractual security commitments.

6. Security incidents

If Future Built becomes aware of a security incident that materially affects information we control, we will investigate, take reasonable containment/remediation steps, and provide notices required by applicable law or contract.

Client-specific incident-response requirements should be written into the applicable agreement when the risk profile warrants them.

7. Compliance and certifications

Future Built does not claim certifications or regulated-industry compliance unless explicitly stated and supported.

Do not infer from this page that Future Built is:

• SOC 2 certified;
• ISO 27001 certified;
• PCI DSS certified;
• HIPAA compliant or willing to act as a Business Associate;
• FedRAMP authorized;
• compliant with any other specific regulatory framework.

If an engagement has formal compliance requirements, those requirements must be identified during discovery and addressed in the architecture, vendor selection, contract, and delivery plan.

8. Vulnerability reporting

If you believe you have found a security issue affecting a Future Built-owned public system, please report it privately rather than exploiting it or publishing sensitive details.

Email: dakota@futurebuiltdigital.com

Include enough information for us to reproduce and understand the issue. Do not access, alter, or retain data that does not belong to you.

9. Questions

Security or privacy questions may be sent to:

Future Built Digital
Email: dakota@futurebuiltdigital.com