Secure Development

A developer-focused digest of GoodFit's Information Security Policy — the parts that touch how we write code, handle data, ship changes, and respond when something goes wrong. This is a summary for day-to-day engineering; the full policy set is the source of truth and is available from security@goodfit.io.

TL;DR — Least privilege, MFA everywhere, never put customer/Sensitive data in dev/test or public AI tools, every production change is peer-reviewed and automatically tested, patch on a clock (Critical ≤7 days), and report anything suspicious to security@goodfit.io straight away.

Highlights at a glance

• Every production change is peer-reviewed. Changes ship through version-controlled repos, GitHub PRs, automated tests, and automated deployment pipelines. A change to production must be approved by a second engineer who did not implement it.
• Dev/test data is sanitized. Sensitive and Confidential data is prohibited in development and test environments. Production data is sanitized/masked before any non-production use.
• Least privilege by default. Access is role-based and kept to the minimum needed. Production access is reviewed at least quarterly.
• MFA is mandatory for network, source code, customer data, and any remote access to production.
• Patch on a clock. Critical vulnerabilities are remediated as soon as practical and within 7 days; see the remediation SLAs.
• AI tools are allowed, with limits. Use only approved tools; never paste customer data, secrets, or source code into a public AI service.

Data classification

Know which bucket the data you're touching falls into — it drives how you must handle it.

Class	What it is	Examples
Sensitive	Most sensitive business information, access strictly limited	Passwords, encryption keys
Confidential	For use by GoodFit and/or its customers only	PII, customer data, financials, internal research, audit reports
Public	Everything else	Non-sensitive, publishable information

Rule of thumb for engineers: customer data and PII are Confidential; credentials and keys are Sensitive. Neither belongs in dev/test environments, personal accounts, personal cloud storage, removable media, or public AI tools.

Handling code and data

• No real Sensitive/Confidential data in dev or test. Mask, pseudonymise, or anonymise before using any personal data in test or analytics.
• Encryption is expected everywhere. TLS 1.2+ in transit, AES-256 at rest. Externally accessible databases are encrypted and served over HTTPS.
• Keep Confidential data on company systems. Don't move it to personal accounts, personal cloud storage, or external drives without approval.
• Secrets stay out of source. Credentials, passwords, and keys are Sensitive data — never commit them, and never paste them into third-party or AI tooling.
• Source code is access-controlled. Authentication (unique ID + MFA, or authorised SSH keys) is required to reach GoodFit's source code and customer data.

Access & authentication

• Least privilege / role-based access. You get the minimum access your role needs; request more via a formal access request (ticket or email) approved by the system owner or a manager.
• Unique IDs only. Never share credentials or use another person's ID — even with their permission. Shared/group accounts aren't permitted for user-level access.
• MFA everywhere. Two of: something you know, something you have, something you are. Required for the network, source code, customer data, and remote access to production.
• Remote access to production is restricted to authorised users with a valid MFA token, over approved VPN/SSH.
• Quarterly access reviews. Management reviews production access at least every quarter; leavers lose access within 24 hours.

Change management & the SDLC

This mirrors our Development Lifecycle and Git Conventions — here's what the security policy formally requires:

• Segregated environments. Development/test and production are separated. Untested code doesn't reach the primary system; changes are staged before production.
• Version-controlled, tracked changes. All production changes go through source/infra repos and change records (GitHub PRs).
• Peer review is required. Every production change needs approval from a second engineer who didn't implement it. Emergency, critical, and major changes additionally need CTO / Engineering Leadership approval.
• Automated testing. Engineers write tests during development; staging runs automated functionality and security testing that simulates user behaviour. A successful staging run gates promotion to production.
• Automated deploy & rollback. Deployments run through automated pipelines. Failed production deploys roll back automatically and notify the implementer.
• Emergency changes may use an expedited path, but must be documented, reviewed, and approved retrospectively as soon as possible.

Vulnerability & patch SLAs

Report any suspected vulnerability to the Engineering team or CTO as soon as practicable. Vulnerabilities are prioritised using OWASP Risk Rating guidance and CVSS where available. Remediation and patching targets:

Severity	Target remediation time
Critical	As soon as practical, within 7 days
High	Within 14 days
Medium	Within 30 days
Low	Within 90 days or next planned maintenance cycle

• Actively exploited / zero-day issues are prioritised and patched as soon as practicable; use compensating controls if immediate patching isn't possible.
• Dependencies matter. Open-source packages (npm, PyPI, container base images, etc.) are covered — automated dependency and container scanning run continuously or on schedule. Keep production on vendor-supported, non-end-of-life versions.
• Penetration tests run at least annually against internet-facing and Confidential-data systems.
• Close a vulnerability only after verifying the fix through testing or rescanning.

System hardening & configuration

• Hardening baselines come from the most restrictive of CIS, NIST, and CSP baseline configurations.
• Configuration changes are controlled through change management; automated deployment applies hardened config consistently from the moment of deployment.
• Cloud infrastructure uses logical isolation, security groups, and identity-based access controls. Public access is limited to approved services.

Logging & monitoring

What every in-scope system must log:

• Authentication events (success and failure).
• Privileged actions (account creation, permission and configuration changes).
• Access to / creation, modification, or deletion of Sensitive or Customer data.
• System errors and security-relevant faults, plus security-tool alerts.

Other essentials: clocks sync to a trusted source and log in UTC; logs are tamper-protected and access to them is itself logged; logs are retained ≥12 months. Confirmed alerts feed the incident process.

Using AI tools

AI coding assistants are welcome within limits (approved tools include Claude/Anthropic, ChatGPT/OpenAI, Cursor, GitHub Copilot, Google Gemini, and HubSpot AI):

• Approved tools only. New tools that generate company IP (code, plans, materials) need CTO or DPO approval before use.
• No confidential data into public AI. Never paste customer data, personal data, source code, secrets/credentials, or trade secrets (roadmaps, business plans) into a public AI service. Use approved enterprise instances for sensitive work.
• Human in the loop. A person reviews every AI output that affects a decision, customer, or deliverable — AI is a draft, you're the editor.
• IP hygiene. Ensure AI-generated content used in products/deliverables is original or cleared for use.

See the full AI and Ethics Policy for the complete rules.

Endpoints & devices

• Company laptops are macOS, enrolled in MDM, with Gatekeeper/XProtect, disk encryption, screen lock, and automatic updates. Don't disable anti-malware controls.
• BYOD (usually a personal phone) is limited to email, calendar, chat, and standard Workspace apps — no downloading/syncing customer data, source code, or Confidential info locally. Devices must be enrolled in mobile management, encrypted, screen-locked, sole-user, and not jailbroken/rooted.
• Prefer company-issued devices for company work whenever one is available.

Incident reporting

If you see something — phishing, a suspicious alert, a lost device, a suspected breach, exposed credentials — report it immediately to security@goodfit.io or your line manager. You won't be penalised for a good-faith report.

• The Information Security Lead triages reported events within one working day.
• Incidents are classified Low / Medium / High by business impact.
• Personal data breaches must reach the DPO at once; notifiable breaches are reported to the regulator within the legal time limit.

Key points for engineers

• No Sensitive/Confidential data in dev, test, logs, tickets, or public AI tools.
• No secrets in source control — use approved secret management.
• MFA enabled; access is least-privilege and requested formally.
• Change goes through a PR with a second-engineer review and passing automated tests.
• Dependencies scanned; known vulns tracked against the remediation SLAs.
• Suspicious activity or exposed data reported to security@goodfit.io without delay.

---

This page summarises engineering-relevant sections of GoodFit's Information Security Policy (V1, 2026-07-30). Where this digest and the full policy differ, the full policy governs. Questions: security@goodfit.io.