01
Security assessment and posture review
A read of what you actually have: identities, exposure, data paths, and the gap between the policy and the configuration. Findings come ranked by what an attacker would reach first.
Cybersecurity & DevOps
Ship faster without widening the attack surface.
Security engineering, compliance readiness, and the delivery pipelines that keep releases safe, built by the people who also run them.
01Security
Security services
Six areas of work, from a first read of your posture through to the controls that keep it that way.
02
Cloud security architecture
Network boundaries, account and tenant structure, key management, and the guardrails that stop a misconfiguration from becoming an incident.
03
Identity and access
Single sign-on, multi-factor enforcement, role design, and joiner and leaver flows that actually remove access. Least privilege written as policy, then enforced in code.
04
Application security and secure SDLC
Threat modeling, dependency and secret scanning in the pipeline, code review standards, and a triage path so findings get fixed instead of filed.
05
Detection and response enablement
Logging that answers the questions an incident asks, alerts tuned to cut noise, and a written runbook your on-call can follow at 3am.
06
AI security and governance
Model access controls, prompt-injection and data-leakage review, and an AI usage policy your teams can actually follow.
A model can be talked into ignoring its instructions, can leak what it was given as context, and can act through tools with more authority than the person asking. We treat that as its own attack surface, and the people who build AI workflows here are the ones who review them.
02DevOps
DevOps and platform
The pipeline is a security control. Most of what keeps a release safe is decided in how it is built, tested, and promoted, long before anyone reviews it.
01
CI/CD
Pipelines that build, test, scan, and deploy without a person copying an artifact between steps. Every release traces back to a commit.
02
Infrastructure as code
Environments defined in code and reviewed like code. If it was clicked into a console, it will drift, and eventually it will be the reason something breaks.
03
Observability
Logs, metrics, and traces that answer a question during an incident rather than after it. Dashboards nobody reads get removed.
04
Release engineering and environments
Consistent environments, controlled promotion, feature flags where they earn their keep, and a rollback path that has been tested rather than assumed.
03Compliance
Compliance readiness
We help you prepare for these frameworks. That means closing control gaps in your systems and assembling evidence an auditor can follow.
Keelfield does not hold SOC 2, ISO 27001, or any other certification, and does not issue attestations. Certification is granted by an independent auditor or certification body, never by the firm that did the engineering work. Anyone telling you otherwise is worth a second question.
01
SOC 2 readiness
We map the trust services criteria to what your systems actually do, close the control gaps in code and configuration, and assemble the evidence your auditor will ask for.
02
ISO 27001 readiness
Scope definition, risk assessment, and the technical controls behind your statement of applicability. We do the engineering work; your certification body does the certifying.
03
HIPAA readiness
Access control, audit logging, encryption in transit and at rest, and the technical safeguards around protected health information. Your counsel owns the legal analysis.
04
GDPR readiness
Data mapping, retention, deletion, and access controls implemented in the systems themselves. Your counsel owns the legal position; we make the systems match it.
04Questions
Common questions
Is Keelfield SOC 2 or ISO 27001 certified?
No. Keelfield holds no security certification and issues no attestation, and any vendor claim like that is worth verifying with the auditor who supposedly issued it. What we do is the engineering and evidence work that gets your organization ready for an audit.
Can you get us certified?
No firm can. Certification is issued by an independent auditor or certification body after they examine your controls, and using the same firm to build and to certify is the conflict the standards exist to prevent. We prepare you for that examination and hand your auditor evidence they can follow.
Do you do penetration testing?
We do security assessment, architecture review, and remediation engineering. Where an independent penetration test is the right instrument, we will say so and work to the findings rather than mark our own homework.
How does AI security differ from the rest of this?
Traditional review asks who can reach a system. AI review also has to ask what the model can be persuaded to do once it is already inside, and how far its tool permissions reach. That changes what you log, what you rate-limit, and who signs off on giving a model write access.
Can you work with our existing security team?
Yes, and that is the usual shape. We take the work your team does not have the hours for, use your tooling and your ticket queue, and leave the standards documented so the work does not depend on us staying.
What if you find something serious during an assessment?
You hear about it that day, not in the report. Anything actively exploitable is raised immediately to a named contact, with the shortest safe mitigation first and the durable fix scheduled after it.
Start with what you already know is wrong
A 30-minute call, no deck. Bring the finding you have been carrying, the audit date you are working back from, or the pipeline nobody wants to touch, and we’ll tell you what we would do about it.
Request a discovery call