Support service
Build security into the architecture
When an audit is coming and identity, permissions and secrets are scattered across services, security becomes a scramble. We model the threats, design identity and access, and map controls to evidence.
- Duration
- 4 to 10 weeks
- Model
- Design and implementation support
- Output
- Threat model and compliance mapping
Signs security is not yet part of the design
Most security findings in audits are not exotic attacks. They are architecture decisions that nobody wrote down.
- An ISO 27001, SOC 2 or customer security review is coming, and nobody knows which controls the system already meets.
- Every service implements authentication and permissions in its own way.
- Secrets live in configuration files, environment variables or chat messages.
- Nobody can say who can access production data today, or who could last month.
- Personal data is copied into logs, analytics and test environments without a clear rule.
- Enterprise customers send security questionnaires that take weeks to answer.
- A penetration test report lists findings, but the underlying causes keep producing new ones.
Controls that come from the design
Security added at the end becomes a list of exceptions. Compliance added at the end becomes a documentation exercise that nobody believes. Both are cheaper and more credible when they follow from how the system is built.
We start with a threat model of the system as it runs: assets, trust boundaries, entry points and the ways they can fail. From there we design identity and access so that they are consistent across services, move secrets into managed storage, and set rules for where personal data may flow.
Each relevant control of the framework you face, such as ISO 27001, SOC 2, GDPR, KVKK or PCI DSS, is mapped to the part of the architecture that satisfies it and to the evidence that proves it. Auditors and customers get answers backed by the system rather than by promises.
Scope
Included
- Threat model of the system and its trust boundaries
- Identity and access architecture across services
- Authorisation model: roles, permissions and service identities
- Secrets management and rotation
- Personal data flows, minimisation and retention rules
- Audit logging design
- Compliance mapping from controls to architecture and evidence
- Implementation support for the highest-risk changes
Not included
- Penetration testing and red teaming
- Formal certification or audit
- Legal advice on regulations
- Security operations centre and incident response services
How the work runs
- Weeks 1 to 2Model the threats. Architecture, data flows and access paths are mapped, and the threat model is built with your engineers.
- Weeks 3 to 5Design the controls. Identity, authorisation, secrets and data flow rules are designed and written down as decision records, starting with the highest risks.
- Week 5 onwardImplement and map. The most important changes are implemented with your team, and each control is mapped to the architecture and the evidence.
- Final weekPrepare for the audit. The compliance mapping, evidence locations and open items are reviewed with you, ready for the auditor or the customer questionnaire.
What you receive
Documents and changes stay in your repositories and your accounts.
Who this service is not for
- Organisations that need a penetration test or a certificate. We design the architecture; testing and certification are done by specialist firms.
- Teams looking for a legal interpretation of a regulation. We map technical controls; legal advice comes from your counsel.
- Projects that want a policy document without changes to the system. The value is in controls that the system actually enforces.
Frequently asked questions
Can you make us ISO 27001 or SOC 2 certified?
Certification is granted by an accredited auditor. We make the architecture ready for it: controls designed into the system and evidence you can show.
Which frameworks do you work with?
Most often ISO 27001, SOC 2, GDPR, KVKK and PCI DSS. The mapping approach works for other frameworks as well.
Do you do penetration testing?
No. We work with the results of penetration tests and fix their root causes in the architecture. For the test itself, we recommend an independent specialist.
How do you handle access to sensitive systems during the engagement?
Access is limited to what each step needs, granted after an NDA and removed at the end. For the threat model we mostly need architecture documentation, configuration and read access.
Will this slow down development?
Designed well, it should not. Consistent identity, managed secrets and clear data rules remove decisions that each team would otherwise make on its own.
Start with a short technical call
Thirty minutes. You tell us which audit or questionnaire you face, and we tell you where the architecture stands.