Security & Access
We Don't Want Your Passwords. We Want the Right Kind of Access.
Good security is mostly about not collecting secrets you don't need. We do collect ordinary contact and project information; authentication secrets are different. Here's what we won't ask you to paste into an intake, and the least-privilege access we'll prefer when access is actually required.
Principles
What We Don't Ask You to Paste Into Intake
- Passwords stay out of ordinary intake.
- MFA and recovery codes stay out of ordinary intake.
- Secret API keys stay out of ordinary intake.
- Production resources intended to belong to the client should, where practical, be client-controlled or transferred to client-controlled accounts.
- The client pays third-party service costs.
- Project access uses official collaborator / team / temporary-account / least-privilege mechanisms where possible.
- SBG does not accept raw shared credentials through ordinary channels; if safe delegated access is unavailable, the access-dependent work may be declined.
- Secrets belong in client/provider-controlled secret / environment systems, not ordinary project notes or SBG messages.
- Access is reduced or removed after completion where appropriate.
Access Checklist
Least-Privilege, When the Time Comes
These are the kinds of access we may coordinate through official collaborator, team, temporary-account, or provider-delegation mechanisms when a project actually requires them. Raw shared passwords, private keys, tokens, MFA/recovery codes, and secret API keys are not accepted through intake, email, portal messages, project notes, or source ZIPs.
- Development platform collaborator access
- Repository collaborator access
- Test accounts
- Payment-provider team / developer access
- Domain / DNS access — only if actually required
- Email-provider access — only if actually required
- Other least-privilege access as needed
Access coordination is project-specific. A checklist item describes access that may be needed; it is not proof that access has been granted or verified. SBG does not accept raw shared secrets through ordinary project channels. If a platform genuinely requires one and offers no safe delegated method, SBG may pause or decline the access-dependent work rather than ask you to send the secret unsafely.
Secure Source Transfer
One Controlled Channel, With Evidence Behind It
When an authorized Audit, Rescue, or eligible Maintenance engagement genuinely requires a source ZIP, SBG opens one authenticated project-specific transfer. The goal is simple: keep proprietary source out of ordinary inboxes and tie the transfer to the correct client and project.
No online storage, network, or transmission system can be guaranteed absolutely secure. SBG uses controlled access, private storage, short-lived permissions, and transfer records to reduce unnecessary exposure.
Technical Source-Transfer Details
Designated source archives use private Cloudflare R2 object storage. Cloudflare documents AES-256 encryption at rest for R2 object data/metadata and TLS protection in transit.
SBG does not provide unrestricted bucket access. Transfers use short-lived signed permissions for specific object operations and preserve authenticated project context, upload completion, integrity-fingerprint evidence, and custody state.
That is the technical version of: source gets a considerably more controlled trip than FINAL-final-v7.zip ricocheting through somebody's inbox.
Source ZIPs are accepted only through the authorized SBG project portal. Email attachments and third-party file-sharing links are not approved source-archive submission methods.
Sensitive & Regulated Data
A Checkbox Is Not Permission to Send the Records
Intake questions may ask whether medical, financial, payment-card, government-ID, children's, employee, or other sensitive data exists so we can evaluate risk and fit. Describe the category first. Do not paste the actual regulated records into intake or ordinary email. If an engagement genuinely requires SBG to handle regulated or unusually sensitive information, we review the legal and technical requirements before accepting access and may require additional written terms, provider validation, a data-processing addendum, Business Associate Agreement, or other safeguards.
SBG does not claim HIPAA, PCI DSS, SOC, ISO, FedRAMP, or another certification merely because a project involves that type of data or uses an underlying provider with its own certifications.
Incidents
Security Incident Escalation
SBG investigates suspected security incidents involving information in its custody and takes reasonable steps to contain and remediate confirmed issues. When a confirmed incident involving client-controlled computerized personal information triggers an applicable legal or contractual notification duty, SBG notifies the affected client in an expeditious manner consistent with the required investigation, restoration of system integrity, applicable law, and any lawful law-enforcement delay. Security, privacy, data loss, and incidents are handled directly and documented carefully.