We address the technical requirements of
NIS2UKSCISO 27001

How it looks today

Before we propose anything, we describe the state we usually find.

The team already uses AI assistants, usually without agreed rules. Code is produced faster, but no one checks what goes into the prompt, where the generated fragment comes from, or whether it passed the same controls as hand-written code.

What we do

We define the scope after an assessment. Rarely do all four elements come in at once.

Rules instead of a gray zone.

We establish what may be pasted into an AI tool and what never — taking into account client data and code covered by contracts. We put generated code through the same review process as hand-written code, without exceptions, because a fragment's origin does not change its risk. We tidy up the access of assistants and integrations, so they get only the permissions they genuinely need. We train the team on concrete examples instead of imposing a blanket ban no one follows anyway.

SemgrepGitLab CIVault

Four stages

01

We set the rules of use

What may be pasted into the tool and what never — taking client data into account.

02

We bring generated code under control

The same review process as for hand-written code, without exceptions.

03

We tidy up tool access

The assistant and integrations get only the permissions they genuinely need.

04

We train the team

Concrete examples instead of a blanket ban no one follows.

What stays with you

Company and client data do not leak through prompts

Generated code passes the same controls as everything else

The team has clear rules instead of a gray zone

Questions we get
most often

How long does it take?+

We define the scope after a call and an assessment. Smaller engagements close in a few weeks; larger ones we split into stages, so the result is visible after the first.

Do we have to give you access to the code?+

Usually not to all of it. In most cases access to the build pipeline configuration and organization settings is enough. We define the scope in writing before we start.

Does our team have to get involved?+

Yes, but not full time. We need contact with someone who knows the system, and a review of our changes. The rest is on us.

What if we already have tools?+

We plug into what already works for you. Replacing a tool is the most expensive and least often necessary way to improve security.

Do we become dependent on you?+

You don't have to. We work with standards and tools your team knows or will quickly learn — not a proprietary method only we understand. Everything is documented and handed over.

Won't this slow down releases?+

We wire controls so they run in the background. If one starts blocking work, we tune it or move it to a different point in the process.

Want to reduce risk
and IT costs?

Book a free call →
We reply within 24h on business days