The most important thing we can do before writing a single line of code is to clarify the division of responsibilities between us and the customer, as well as the classification of the solution and data. What requirements does the customer have, and what requirements comes from the government or other parties? Application security (AppSec) resources should already be part of the team in this phase to ensure that we meet security requirements and expectations.
We must also outline what we will do when a security incident occurs - what requirements are we facing, what is needed for successful disaster recovery, backup, and similar measures, and what will the consequences of downtime be for the customer?
1 - Roles and responsibilities
A lack of clarity in our responsibilities and those of others can have huge consequences for a project, so this must be clarified beforehand. It is especially important if companies other than us and the client are involved, as tasks and roles tend to fall through the cracks because everyone thinks “someone else” will handle it.
Bouvet conducts development projects in many different ways, where we take more or less responsibility for project management, planning, development, quality assurance, and not least the operation and management of the solution. We also involve our own, the client’s, and third-party equipment both during development and management of the solution.
Regardless of how the project is executed, it is important that we are aware of how responsibilities are divided. This should be regulated in the agreement with the client, so we must ensure that we:
Have control over our roles and responsibilities
Have contact points with all involved parties
Can follow up on deviations quickly so as to avoid misunderstandings or problems later in the project cycle
Note
The role delivery manager is responsible for security in the delivery, and is responsible for following up on any security concerns.
Operation and Management - Bouvet
The project may also fall under our ISO certifications. This is especially the case if we use our own equipment or infrastructure for development, operations, or management on behalf of the client. If this is the case, it means we have greater overall responsibility for the security of the solution, and it is important that the delivery team is aware of this.
All resources managed by the delivery team must be handled in line with all other infrastructure in Bouvet, so the team must have routines for patching and maintenance or ensure that this is handled. Be aware that client resources and data must be handled with separate backup routines so we do not mix data across clients or with our own internal data. Feel free to contact Internal IT & Security to see what they can deliver and assist with to simplify delivery and management.
Bouvet’s Statement of Applicability/Declaration of Application (SOA) for ISO 27001 and ISO 42001 address various controls related to information security and how we should relate to them. If we take on this role, your regional quality manager can assist with advice and guidance to ensure that our responsibilities are met.
Operation and Management - Client or Third Party
If we are only responsible for the development of the solution, it is important that we have defined the interface between us and the organization that takes over and continues to operate the solution:
How should handover occur
How do we ensure that the necessary hardware and systems have been set up and configured correctly
How do we ensure that all parties are aware of the requirements related to deployment, operational incidents, error corrections and similar
Tip
Document the roles and responsibilities and other relevant information in the source code system along with other documentation. This increases its visibility and everyone always knows where the information is.
Use of AI
If AI is included in the delivery, you must also clarify how this is regulated in the agreement. AI opens up many opportunities but also introduces new risks in addition to amplifying existing risks, particularly related to privacy. The AI Act is not yet enacted in Norway, but it is expected to come in the near future, and projects that build solutions covered by this should ensure compliance with the proposed AI Act in Norway.
AI as a tool
If you are going to use AI tools, you must ensure that this has been clarified with the client and that the agreement takes it into account. AI can be a fantastic tool, but it also opens up scenarios where we or the client can be harmed if responsibility and use are not clarified. If our equipment or infrastructure is to be used for new tools, this must be clarified with Internal IT & Security before the project starts so that licenses and necessary risk assessments can be carried out.
Most organizations operate with various classification levels for both data and systems. The classification level dictates how data is used, where it is stored, and who can access it. These are key requirements for any development project and must be clarified in advance.
In short
Most organizations have different classification levels for both data and systems. The classification is often based on how data is used, where it is stored, and who can access it. This is a key requirement for any development project and must be clarified in advance.
Classification
Most organizations have routines and processes for data classification, typically distinguishing between these or similar levels:
Open
Internal
Confidential
Restricted
Depending on this classification, there may be different requirements for securing data. Open data typically has no restrictions, while data classified as “restricted” may have limitations such as:
strict requirements for access
information can only be processed or stored in approved systems
requires multi-factor authentication before access
has restrictions regarding the use of cloud services or the geographical location of where data is stored
This needs to be clarified with the client at the start of the project to ensure compliance. If the client does not use data classifications, one should still assess the sensitivity of the data to be processed to ensure that necessary measures are implemented.
Privacy
If the delivery team is to handle personally sensitive information, it is important that the team familiarizes itself with the requirements surrounding this. The Norwegian Data Protection Authority has published a guide for “Software development with built-in privacy” (in Norwegian) which provides useful insight into the issue.
Important
Norway has implemented GDPR into Norwegian law through Personopplysningsloven. All our deliveries have to consider the definitions and requirements which follow from this. Also remember that we are likely to be subject to data processing agreements that might carry even stricter requirements.
The purpose of the GDPR is to ensure the privacy rights of individuals through regulating the use of Personally Identifiable Information (PII). The GDPR has a number of requirements that define how PII can be used and for what. PII is defined as
“any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”
Privacy may look like a complex and difficult topic, but generally
Any piece of information that can be tied to an individual is PII
Any use of PII requires a valid basis for processing it
The data subject must consent to the use of the data
Data minimization is a requirement - do not collect information unless it is needed
The information should have an end-of-life - a date where you consider deleting it. Do not store it for longer than needed.
The user has a right to be “forgotten” - also if you restore from a previous backup
If we process this type of information on behalf of clients, they will normally require that we sign a data processing agreement. If this is not in place, it must be discussed with the client’s representative.
Data for Use During Development and Testing
If data is used in connection with development and testing, it is important to consider classification and sensitivity. Development environments often have a different level of security than production environments, and this practically means that we cannot always use real data for development.
The team must check the need for anonymizing the data before it is used outside the production environment, so as to maintain the need for data amount, filling rate, and quality while ensuring that the client’s data does not go astray.
This is especially important if development occurs in Bouvet’s infrastructure but with a production environment located at the client’s site. In such cases, it is vital that Bouvet has documented routines regulating where and how data is stored and used, and how and when it should be deleted. This must be clarified in consultation with the client so that there is no doubt about responsibility, duties, and risk.
Artificial Intelligence and Data
If you are building solutions with, or by means of artificial intelligence, the proposed AI law imposes requirements for data quality, especially for high-risk systems. This is specifically mentioned for these as they can be used in situations that could have serious consequences for individuals beyond the privacy considerations described in the Personal Data Act. AI systems that are not classified as high-risk must also comply with requirements for marking information produced by AI.
Another important consideration is learning in the AI model: Few companies will accept that AI models learn from their data, as there have been several examples of training data being reconstructed afterwards. The use of enterprise agreements often limits the AI model’s ability to learn from customer data - this is a point that must be verified by us when we build solutions.
Be aware that the Personal Data Act also applies to AI systems. When evaluating vendors, we have seen several cases where AI vendors provide services outside the EU, where extra careful assessments and reviews are necessary to ensure that we comply with the requirements laid down in the law.
If you have questions about using AI, you can create a case through BSD or on #ai (Slack).
If a catastrophic event occurs, we must know who to contact and what requirements the solution and delivery team must adhere to. This not only includes typical availability requirements but also how long recovery can take, how it should be done, and what is an acceptable data loss.
Business Continuity Planning is not an IT-technical subject. But it is our responsibility as suppliers of an IT system to remind the customer that the system can become unavailable.
The answer from this planning will help describe the requirements for the solution’s robustness and security level, and is crucial for finding the right balance of cost and performance for the system.
Here it is important to consider
The criticality of the solution
Possible workarounds if the solution is unavailable
Consequences or extra work resulting from unavailability or when the solution becomes available again.
Customer Expectations
Do we have a Service Level Agreement with the customer that regulates uptime, availability, and similar, or does the customer have implicit expectations for this?
This must be clarified so that the team is aware of the consequences of downtime. In many projects, cloud components are used, where not all variables are under one’s control. Therefore, it is important early in the project to clarify the actual needs with the customer. We can ensure redundancy on all fronts if the customer wants it, but it will then cost accordingly.
Incident Management
All customers in Bouvet should have a defined contact point for incidents in Kunder (CRM). If there are other contact points from the team to the customer, such as a security operations center (SOC) or similar, it is also wise to document this so that incidents can be resolved as quickly as possible.
If an incident occurs and the customer or others need to contact the team, the usual practice is for the delivery manager to be the formal contact point in the Bouvet team.
Backup
Backup is important in all projects. Even if we do not have responsibility for the operation of infrastructure, source code systems, or other tools in many projects, we should be familiar common backup strategies, so that we can design and implement a solution that allows for these.
If we are responsible for operations, we are also responsible for ensuring that backups are performed. Common terms here are:
Recovery Time Objective (RTO) - acceptable time to achieve normal state after a failure
Recovery Point Objective (RPO) - acceptable data loss after a failure (measured in time)
The backup and recovery solution must be designed based on these requirements, and we must ensure that this is maintained. Together with the customer, we must determine:
How much?
Which data and systems should be subject to the backup regime. Can we differentiate between them?
How often?
Should we take backups once a week, every night, or every hour?
How far back?
How long should we store the backups?
A common approach to backup is to run:
Daily backups - stored for 30 days
Weekly backups - stored for 6 months
Monthly backups - stored for 2 years
It is also important to consider where the backups are stored, so that one is best prepared for catastrophic events. This can be solved by having offline and offsite backups, i.e., backups stored on, for example, tape and kept at a different physical location than other backups.
Test!
Backups that are not tested have no value - implement a strategy that includes testing restore from backup!
Disaster Recovery
Disaster Recovery in the planning phase involves developing a plan for what should be done to return to normal state as quickly as possible. It can be useful to think of this as “actions on,” i.e.; “If X happens, we do Y”.
Recovery
It will not be necessary to recreate services in all disaster events. Often, less extensive and manual error correction can suffice. Regardless, one should always have a plan for complete recovery. Having this can save you in most situations.
Can infrastructure be recreated correctly and quickly enough?
Document resources, dependencies, and operational procedures
The use of Infrastructure as Code (IaC) will be a significant factor here
Data and databases
Total / bulk recovery: How do you recover large amounts of data / entire volumes?
Individual files: How do you recover a single file, table, row or column?
Support systems
Remember that support systems can play an important role in the overall system. These must also be replaceable or recoverable in the event of incidents
Examples: Git, CI pipeline, logging, and monitoring
Scenarios to Discuss
Deleted service: How do you restore a service that has been deleted?
Corrupt service: Do you repair or restore a VM or other services with problems?
Unavailable service: What happens if the services become unavailable? Here you need the definition of what is temporary / short-term downtime. Should you deploy a new service, do you already have one running as a hot-swap, or is it okay without one for a period?
Compromised security: How do you handle it when a password has been leaked in some way?
Expired password: How do you resume operations if a password or certificate has expired?
Compromised identity / service user: What do you do if a managed identity or a service user has been compromised?
Unavailable passwords: What do you do if the key vault service in the region you use goes down? Do you have backup and failover in another region?
Malware: How do you recover the system after a malware attack? Do you need a partial or total rebuild of all services?
Confidentiality breach: How do you handle someone gaining access to the service(s) you operate?
Compromised admin: Do you need to plan for what happens if the owner of the subscription deletes your entire Azure subscription?
Critical vulnerability: What happens when someone discovers a critical vulnerability in your application? It may be wise to have protocols ready for when you need to decide whether to shut down the service.
The use of artificial intelligence (AI) has exploded in recent years, and the technology has advanced to the point where it can be a useful tool for brainstorming solutions, writing, debugging, or evaluating code. But what does this mean for security?
This page is about the use of AI in the development cycle, not the general use of AI solutions. The goal is to use AI as a productivity tool without losing control of security, quality, and traceability.
Use of AI tools
Remember that Bouvet and most clients have guidelines for the use of AI that must be followed. It is not permitted to use AI tools without explicit approval from Bouvet or the client.
What we are allowed to use
On Bouvet equipment, we can only use AI tools that are explicitly permitted in Bouvet’s AI policy. On client equipment, we can only use tools that the client has approved.
The reason is simple: AI tools often process sensitive information and can perform actions that affect codebases, builds, and deliveries.
Even though we can use a tool technically, that doesn’t mean we should use it. If a new tool can provide value in the project, create a BSD ticket for evaluation.
Practical advice for safe AI use in development
To get value from AI in development without unnecessarily increasing risk, the team should have some simple, shared working rules. These should be used in daily work, not just as policy on paper. Each team should develop their own rules and procedures that fit the context they work in, so that both our and the client’s security requirements can be met.
This is what we should do
use AI on bounded tasks with clear goals and a well-defined framework
treat AI contributions as third-party code: You must understand and be able to explain the code before it is merged or run
document AI usage where it is relevant for traceability and audit
use as little data as possible in prompts (data minimization), and only share what is needed for the task
restrict AI tool access to the minimum necessary level
This is what we should avoid
pasting secrets, personal data, or customer information into prompts
letting AI make architectural or security decisions without human review
disabling review or test requirements because the code looks right at first glance
giving tools broad repo, cloud, or production access without clear need and approval
letting AI merge, deploy, or rotate secrets without explicit human approval
The goal is not to slow down development, but to use AI in a way that is safe, predictable, and traceable.
Running AI-generated code
Code and scripts suggested by AI should always be reviewed before running on a development machine. Pay special attention to commands that download content, change file permissions, start background processes, or write to system areas. If you run the AI tool in a confined sandbox, you reduce the risk and can to a greater extent let the AI tool work autonomously.
Prompting in practice
Good prompting practices reduce risk and increase quality. A useful principle is that the prompt should be specific enough to give a good answer, but limited enough that you maintain control of the data and results.
This is what we should ask for
describe requirements and framework first (language, framework, security requirements)
ask for small, reviewable changes rather than large rewrites
ask for explicit assumptions, limitations, and uncertainty
ask for test suggestions together with code suggestions
ask the AI to explain the security consequences of the proposed solution
ask for alternatives with pros and cons when the solution affects security or operations
This is what we should avoid
prompts that contain secrets, tokens, or customer data
prompts that ask AI to bypass policy, logging, or security controls
prompts that give AI open authority to “fix everything” in the entire codebase
prompts that ask AI to make changes directly to production-like environments without review
prompts that mix multiple unrelated tasks so that the result becomes difficult to quality assure
Unless explicitly approved, AI tools should not have access to data beyond what is needed for the task.
Check that the repository does not contain data files, secrets, or other sensitive information. Use .gitignore, git pre-commit hooks with secret detection, and key vaults to reduce the risk of leaks.
AI-specific threats in the development cycle
When AI is used in development, threats emerge that are not always covered by traditional controls:
prompt injection in code, documentation, or issues that affect the agent’s behavior
data exfiltration via prompts, logs, plugins, or integrations
hallucinations that introduce false APIs or insecure patterns
poisoned context from compromised dependencies or malicious code examples
excessive reliance on autonomous execution without human oversight
These threats must be handled with technical barriers, clear processes, and active monitoring.
Agentic development, instruction files, and guardrails
Agentic tools can analyze codebases, suggest changes, create pull requests, and in some cases perform actions automatically. This requires stricter control than typical code assistance.
Leakage of sensitive data
Some AI tools can commit and push code automatically. Ensure that sensitive information such as passwords, certificates, and data does not leak.
For teams that want to get started quickly with safer agentic development, there is an internal Bouvet repository with examples and patterns: bouvet-ai-harness. The repository offers a set of repository artifacts and working methods that make AI-assisted development more consistent, efficient, and measurable, and can be used as a practical starting point for instruction files, workflows, and measurable quality criteria.
Recommended guardrails:
use instruction files that define what the agent can and cannot do
keep instructions concrete, testable, and project-specific
restrict permissions (least privilege) for repos, CI/CD, and cloud access
require human review before merge and deploy
block automatic changes to security-critical files without explicit approval
log agent actions so that contributions are traceable and verifiable
use hooks from git and AI tools to establish additional guardrails
For teams that actively use instruction files, these should be treated as a security control equivalent to CI/CD policy.
Quality assurance before merge
AI contributions must not go to production without full quality assurance. At minimum, the following should be in place:
code review by a developer who understands the change
relevant tests, including security tests where applicable
control of dependencies and license requirements
verification that secrets have not been introduced
assessment of whether the change affects the threat model or security requirements
A security checkpoint is a control point during a project where requirements must be met before proceeding.
Depending on the security level a delivery aims to achieve, it may be necessary to define mechanisms for assessing security at fixed points in the development cycle, known as security checkpoints.
These can be defined between logical phases in the project, for example, between the design and development phases, or when transitioning from development to the first release in production. Other and additional checkpoints can also be defined, entirely depending on the requirements the delivery team must adhere to.
In a study by IBM it was determined that defects in applications developed for the U.S. military cost significantly less to fix early in the process compared to later.
By implementing security checkpoints, it becomes easier to catch weaknesses early and to ensure compliance with security and quality requirements. A typical practice using checkpoints could include
creating a design of the project before the development cycle starts
ensuring that implementation follows the design
verifying that design and implementation actually match before going into production
AI-specific security checkpoints
For solutions that use AI, dedicated checkpoints should be established before production deployment. The goal is to ensure that data, model behavior, and operational readiness are reviewed and documented before the solution is exposed in production.
A practical minimum is to introduce the following gates:
1. Data review gate
Before model training, fine-tuning, or major changes to the data basis, the team should document:
which data sources are used, ownership, and permitted usage purpose
a basic data quality assessment (representativeness, missing values, noise, duplicates)
identified privacy and security risks in the data basis
decisions on any data limitations, filtering, or rejected datasets
2. Evaluation and V&V gate
Before production, the model should be verified and validated against defined acceptance criteria:
a documented evaluation setup with relevant test sets and scenarios
assessment of security and misuse scenarios (for example prompt injection and unwanted tool usage)
clear boundaries for when the model must not be used without human oversight
a go/no-go decision with rationale
3. Logging and monitoring gate
Before production, the operations team should verify that required observability is in place:
which events must be logged (model calls, access changes, failures, anomalies)
how logs are protected against tampering and unauthorized access
which alerts and thresholds should trigger follow-up
who is responsible for ongoing monitoring and incident handling
