Software Development for Norwegian Companies: GDPR via the EEA, NOK and Overlap
Founder & Lead Engineer, RAITHub
A Norwegian company can hire an offshore software development company under the same rules as an EU firm: the GDPR has applied in Norway through the EEA Agreement since 20 July 2018. If the team can see personal data, you need a processing agreement, standard contractual clauses and a transfer assessment. Expect 4 shared working hours with Oslo in winter and 5 in summer.
This guide is for founders, product owners and CTOs at Norwegian startups and small companies who are weighing an outside team for a web product. RAITHub is a software studio in Dhaka, Bangladesh, so we have an interest in the answer. We are offshore, not nearshore, we deliver in English only, and we have no office or entity in Norway or anywhere in the EEA. The GDPR transfer mechanics (which SCC module, how to run a transfer impact assessment) are covered in depth in outsourcing software development for EU startups; this post covers what is specific to Norway. This is general information, not legal or tax advice. Confirm legal points with your adviser and with Datatilsynet, and tax points with your accountant.
Does the GDPR apply to a Norwegian company that outsources development?
Yes, fully. Norway is not in the EU, but Datatilsynet states that "the GDPR was incorporated into the EEA agreement and became applicable in Norway on 20 July 2018", and that "Norway is thus bound by the GDPR in the same manner as EU Member States" (Datatilsynet: regulations). In Norwegian law the GDPR sits inside the Personal Data Act (personopplysningsloven), which Datatilsynet names as "the main legislation directing our work" (Datatilsynet: about us).
Two practical consequences follow for a Norwegian buyer:
- Moving data between Norway and the EU is not a third-country transfer. Hosting in Stockholm, Frankfurt or Dublin is inside the EEA, so it needs a normal processing agreement but no transfer tool.
- Bangladesh is outside the EEA and has no adequacy decision from the European Commission (European Commission: adequacy decisions). If developers in Dhaka can access personal data, even by remote login, that is a transfer. The usual safeguard is the standard contractual clauses (SCCs), plus a transfer impact assessment. The EU startup guide walks through both step by step, and none of it changes for Norway.
What is Norwegian is the authority. If a customer complains, or you report a breach, you deal with Datatilsynet, in Norwegian or English. Datatilsynet describes its job as supervising that "authorities, companies, organisations and individuals follow data protection legislation" through "information, dialogue, complaints handling and inspection" (Datatilsynet). For small companies, the EDPB's data protection guide for small business, which Datatilsynet links from its English site, is a readable starting point.
What should a Norwegian company own, and what should the vendor own?
You are the controller: you decide why and how personal data is processed, so the records, the assessments and the relationship with Datatilsynet stay with you. The vendor is a processor and should supply facts, sign the paperwork and follow your controls. A split that works:
| Task | Your company (controller) | Offshore vendor (processor) |
|---|---|---|
| Record of processing activities | Keeps it and adds the vendor | Describes exactly what it touches |
| Data processing agreement (Article 28) | Issues your template, or reviews the vendor's | Signs it, names sub-processors |
| Standard contractual clauses | Chooses the module with your adviser | Signs unchanged and fills the annexes with specifics |
| Transfer impact assessment | Owns the conclusion | Answers questions about its set-up and country |
| Breach notification to Datatilsynet | Decides and notifies | Tells you without delay, with facts |
| Production hosting and accounts | Owns the cloud account in the EEA | Deploys through your pipeline |
The lowest-cost safeguard is design, not paperwork. If the team works on code, synthetic test data and staging, and never on production personal data, most of the transfer question shrinks. That is how RAITHub works by default: production in your own EEA cloud account, synthetic seed data, deploys through your CI and human access to production only when you approve it. We sign DPAs and SCCs and follow your controls. RAITHub is not SOC 2 or ISO 27001 certified and makes no compliance claim; whether your arrangement meets the GDPR is your adviser's call. How we handle code and access is on the security page.
How much does a development team cost in Norway, in NOK?
Start from the official salary data. Statistics Norway (SSB) reports average monthly earnings of NOK 80,770 in the information and communication industry in November 2025, against NOK 62,070 across all industries (SSB: earnings). SSB does not publish a separate "software developer" line in that release, so treat the industry figure as a proxy.
Turning that into an hourly figure takes an assumption. At 37.5 hours a week, a month has about 162.5 working hours, so NOK 80,770 is roughly NOK 497 an hour in gross salary alone. That is before holiday pay, pension, employer social security contributions, equipment, office and the months it takes to recruit. Your accountant can give you the true loaded cost for your company.
The table applies that arithmetic to one illustrative first release: sign-in, one core workflow, payments, an admin area and tests, about 800 engineering hours. The two outside-team rates are assumptions chosen to show how line items combine. They are not RAITHub prices: RAITHub publishes no rates and gives a fixed written quote after a free technical audit.
| Line item (illustrative) | Assumed hours | In-house, salary only (NOK 497/h) | Outside team at NOK 450/h | Outside team at NOK 900/h |
|---|---|---|---|---|
| Discovery and written specification | 50 | NOK 24,850 | NOK 22,500 | NOK 45,000 |
| UX and interface design | 80 | NOK 39,760 | NOK 36,000 | NOK 72,000 |
| Sign-in, roles and accounts | 70 | NOK 34,790 | NOK 31,500 | NOK 63,000 |
| Core workflow | 260 | NOK 129,220 | NOK 117,000 | NOK 234,000 |
| Payments: cards plus Vipps MobilePay | 90 | NOK 44,730 | NOK 40,500 | NOK 81,000 |
| Admin area and reporting | 60 | NOK 29,820 | NOK 27,000 | NOK 54,000 |
| Privacy engineering: export, deletion, retention | 40 | NOK 19,880 | NOK 18,000 | NOK 36,000 |
| Automated tests and QA | 120 | NOK 59,640 | NOK 54,000 | NOK 108,000 |
| Deployment and handover | 30 | NOK 14,910 | NOK 13,500 | NOK 27,000 |
| Total | 800 | NOK 397,600 | NOK 360,000 | NOK 720,000 |
Read the in-house column with care. It is salary only, for one developer, and one person rarely covers design, backend, frontend and testing at the same depth. The honest comparison is not "cheaper per hour" but "what does the whole release cost, and who carries the risk if it slips". A fixed quote moves that risk to the vendor; fixed price vs time and materials explains the trade-off, and the MVP cost estimator lets you change the scope and watch the hours move. Sourced hiring rates on the Bangladesh side are in the cost to hire developers in Bangladesh.
What does adding Vipps MobilePay to a web app involve?
Norwegian consumers expect Vipps at checkout, so price it as its own line, not as a checkbox on "payments". Vipps MobilePay publishes an ePayment API for Vipps, MobilePay and card payments, a Recurring API for subscriptions and a Login API, with a merchant test environment and test users (Vipps MobilePay developer docs).
The ePayment API is a two-step model: you create a payment, the customer approves it in the app, and you capture all or part of the amount later, with cancel and refund as separate operations (ePayment API guide). That changes your data model. "Authorised" is not "paid": for a web shop, capture usually happens when the goods ship. The API sends webhooks for created, authorised, captured, cancelled, refunded, aborted, expired and terminated payments, and the docs warn that "you should not rely on webhooks alone" and should poll the API when webhooks are delayed (ePayment webhooks).
A minimal TypeScript sketch of the state handling, as engineering guidance:
// Vipps MobilePay ePayment: map webhook events to the order state you store.
type OrderPayment = 'pending' | 'authorised' | 'captured' | 'refunded' | 'failed'
const EVENT_TO_STATE: Record<string, OrderPayment> = {
'epayments.payment.created.v1': 'pending',
'epayments.payment.authorized.v1': 'authorised',
'epayments.payment.captured.v1': 'captured',
'epayments.payment.refunded.v1': 'refunded',
'epayments.payment.cancelled.v1': 'failed',
'epayments.payment.aborted.v1': 'failed',
'epayments.payment.expired.v1': 'failed',
'epayments.payment.terminated.v1': 'failed',
}
export function nextState(current: OrderPayment, eventName: string): OrderPayment {
const next = EVENT_TO_STATE[eventName]
if (!next) return current
// Webhooks can arrive late or out of order: never move a captured
// or refunded order back to an earlier state.
const rank: Record<OrderPayment, number> = { pending: 0, authorised: 1, failed: 1, captured: 2, refunded: 3 }
return rank[next] >= rank[current] ? next : current
}
// A scheduled job should also poll "get payment details" for any order
// still pending or authorised after a few minutes, because the docs say
// not to rely on webhooks alone.
Test the unhappy paths before launch: a customer who closes the app mid-approval, an authorisation that expires, a partial capture followed by a refund, a webhook that arrives after your polling job already updated the order. The guide to testing payments and webhooks lists the cases.
To be plain about proof: RAITHub has shipped Stripe payments in production, in PropDesk's rent collection, and bKash, Nagad and SSLCommerz in TheSkinProof, which is the founder's own venture rather than a client project. RAITHub has not shipped a Vipps MobilePay integration. That part of any quote is priced and tested as new work, and this section is guidance from Vipps MobilePay's public documentation.
How many working hours does Oslo share with Dhaka?
Dhaka is UTC+6 with no daylight saving. Oslo uses Central European Time, so on a 9:00 to 18:00 day at both ends, you share 4 hours in winter and 5 in summer, all in your morning.
| Oslo season | Dhaka ahead by | Shared hours | Window in Oslo time | Window in Dhaka time |
|---|---|---|---|---|
| Winter (CET, UTC+1) | 5 hours | 4 | 09:00–13:00 | 14:00–18:00 |
| Summer (CEST, UTC+2) | 4 hours | 5 | 09:00–14:00 | 13:00–18:00 |
In practice, a 09:30 stand-up in Oslo lands in the Dhaka afternoon, questions get answered before your lunch, and the day's work is waiting in a written handoff when you start the next morning. What works less well is decisions late in your afternoon: they wait until the next day unless they are written down. The working week, and how it handles Norwegian public holidays and your summer holiday weeks, is agreed per client when the engagement starts.
Is it a problem that RAITHub works in English only?
For most Norwegian tech teams, no: product, engineering and tooling usually run in English already. It matters in two places. First, the interface: Norwegian (Bokmål, and Nynorsk if you need it) copy should come from you or your translator, and we build the app so all text lives in translation files, with tests that fail if a string is missing. Second, legal and customer-facing documents: privacy notices and terms in Norwegian are your adviser's work, not ours. If your team needs meetings and specifications in Norwegian, choose a local vendor.
What about VAT on an invoice from a Bangladeshi vendor?
Norway is in the EEA but outside the EU VAT area, so the EU reverse-charge guidance in our EU startup post does not carry over directly. Norway has its own rules for services bought from abroad, published by the Norwegian Tax Administration (Skatteetaten). This is general information, not tax advice: ask your accountant how an invoice from a foreign software supplier is treated for your company. RAITHub issues invoices and answers your accountant's questions about them; it gives no tax advice.
Why RAITHub for this
- The EEA paperwork is routine. We sign your DPA and the SCCs, list sub-processors, and fill the annexes with concrete, checkable measures rather than "industry-standard security".
- Data stays in your EEA account by design. Production in your cloud, synthetic data in development, deploys through your pipeline. That is the default, not an extra.
- Tested money paths. PropDesk, the property management platform RAITHub built, collects rent through Stripe and runs 1,024 automated tests. Sundor Skin, a B2B wholesale platform, enforces row-level security across 146 PostgreSQL tables with 530+ tests.
- Fixed quotes, not open meters. A free 15-minute technical audit, then a fixed written quote, as fixed scope or a dedicated monthly team. You own the IP and an NDA is standard. The MVP development service sets out what a first release includes.
- A morning overlap every working day, 4 to 5 hours with Oslo, plus written daily handoffs.
When you don't need us
- Your data must never be reachable from outside the EEA, even to debug an incident. Choose an EEA-based vendor.
- You need delivery in Norwegian. RAITHub works in English only.
- A buyer or investor requires a SOC 2 or ISO 27001 certified supplier. RAITHub holds neither.
- You want developers placed inside your team under your own management. RAITHub does not offer staff augmentation.
- You need a native iOS or Android app. RAITHub builds web applications and PWAs only.
- A Norwegian SaaS product or a no-code tool already does the job. Use it, and spend the budget on customers.
Whoever you shortlist, run the checks in is it safe to hire a Bangladesh software agency; they apply to us too.
Sources checked on 1 October 2026. General information only; confirm legal points with your adviser and Datatilsynet, and tax points with your accountant.
If none of those rule us out, book the free 15-minute technical audit. Bring a one-page description of the first release, the payment methods your customers expect, and whether the team would ever need to see production data.
Frequently asked questions
Does the GDPR apply in Norway?
Yes. Datatilsynet states that the GDPR was incorporated into the EEA Agreement and became applicable in Norway on 20 July 2018, and that Norway is bound by it in the same way as EU member states. It is part of Norwegian law through the Personal Data Act.
Can a Norwegian company use developers in Bangladesh?
Yes. Bangladesh has no adequacy decision, so if the developers can access personal data you need a processing agreement, the standard contractual clauses and a transfer impact assessment. If they work only with code and synthetic data, the exposure is much smaller. Confirm your set-up with your adviser.
Who is the data protection regulator in Norway?
Datatilsynet, the Norwegian Data Protection Authority, an independent body set up in 1980. It handles complaints, breach notifications and inspections, and publishes guidance in English at datatilsynet.no.
How much does a developer cost per hour in Norway?
SSB reports average monthly earnings of NOK 80,770 in information and communication in November 2025. At about 162.5 working hours a month, that is roughly NOK 497 an hour in salary alone, before holiday pay, pension, employer contributions and recruitment costs.
Has RAITHub built a Vipps MobilePay integration?
No. RAITHub has shipped Stripe, bKash, Nagad and SSLCommerz payments, but not Vipps MobilePay. A Vipps integration would be scoped, priced and tested as new work, following the ePayment API documentation.
How many hours overlap between Oslo and Dhaka?
On a 9:00 to 18:00 day at both ends, 4 hours in winter (09:00 to 13:00 Oslo time) and 5 hours in summer (09:00 to 14:00). Dhaka is UTC+6 with no daylight saving. Everything outside that window runs on written daily handoffs.
Related posts
Ready to discuss your project?
Book a free 15-minute technical audit with our engineering team.