How we handle access, data and change.
Taking responsibility for an organization's systems means holding access to them. This sets out how that access is granted, where client data sits, and how change is controlled, so it can be assessed before an engagement rather than during one.
Access
Every person who can reach a client system is named, individually accountable, and no more privileged than the work requires.
- Named individual accounts. No shared credentials, ever, including for infrastructure.
- Multi-factor authentication on every account with access to a client environment.
- Least privilege by default, with elevation that is requested, time-bound and logged.
- Access is granted in the client’s own directory wherever the platform allows it, so the client can see and revoke it without asking us.
- Access is reviewed on a schedule agreed with the client, and removed the day someone leaves the engagement.
Where client data lives
In the client’s accounts. Ferrafox operates systems; it does not accumulate copies of what is in them.
- Systems run in the client’s own cloud subscriptions and tenancy, under the client’s ownership.
- Production data is not copied to Ferrafox devices or infrastructure as a matter of routine.
- Development and testing use synthetic or masked data. Where a genuine case requires production data, it is agreed in writing first, scoped, and removed afterwards.
- Credentials and secrets are held in managed stores inside the client’s environment, never in code, tickets or messages.
Change
What changed, who changed it, why, and how to put it back: available afterwards, not reconstructed afterwards.
- Changes are reviewed before they reach a production environment.
- Infrastructure is defined as code, so the environment can be inspected and rebuilt.
- Releases are reversible. A change that cannot be undone is planned as such, explicitly, in advance.
- Architectural decisions are recorded with their reasoning, including what was rejected.
Working practice
The ordinary discipline that makes the rest of it true.
- Full-disk encryption and screen lock on every device used for client work.
- Dependencies and platform versions are patched as continuing operational work, not as a project.
- Vulnerabilities surfaced by monitoring are triaged and remediated on an agreed timeline.
- Confidentiality obligations are contractual and apply to everyone working on an engagement.
When something goes wrong
Told early, told accurately, and told by us.
- A suspected incident affecting a client system is reported to that client without waiting for certainty about its extent.
- We investigate, contain and record what happened, including what we did not yet know at each point.
- Notification obligations belong to the client as data controller; Ferrafox provides the facts they need to meet them.
- What the incident taught goes back into the architecture. That is the point of running a loop.
What Ferrafox does not claim
Ferrafox holds no security certifications or attestations. No ISO 27001, no SOC 2, no vendor partner status, and no badges it has not earned. The practices above are how the company works, not a third party’s verification of it. If your procurement requires an audited standard, say so early: we will tell you honestly whether we can meet it today rather than after a selection process.
Security questionnaires and supplier due-diligence reviews are welcome and answered directly, including where the answer is no.