Security
Work involving financial or health data needs clear boundaries. We document data handling, access, and incident responsibilities before an engagement begins.
Before an engagement begins, we agree what data is needed, where it may be processed, who may access it, and when it should be deleted. We prefer de-identified, synthetic, or representative data where that is enough for the work.
Project access is intended to be limited to the people and systems needed for the agreed scope. Authentication, logging, review, and offboarding requirements are documented in the services agreement and project security plan.
We plan for version control, change review, dependency checks, secret management, and traceable model artifacts. The exact controls depend on the client environment and are confirmed before production work starts.
Incident responsibilities, escalation contacts, and notification expectations are agreed with each client. If a suspected issue affects client work, we investigate it promptly and communicate what is known, what is affected, and what happens next.
Machine learning systems carry risks that ordinary software does not: training data can be poisoned, models can leak information about the data they were trained on, and deployed endpoints can be probed by adversarial inputs. Our governance frameworks address these directly — with input validation at inference time, monitoring for anomalous query patterns, controls on who can retrain or replace a model, and documentation of every model's lineage so that unexpected behavior can be traced to its source.
To report a security concern, contact security@auditlynk.com. We review reports as promptly as possible and will reply when we have enough information to respond usefully.
Security reviews are a normal part of our sales process. Ask us anything.