Greek financial firms considering Claude or Microsoft 365 Copilot have a real data-residency decision to make, but AWS Bedrock in Frankfurt is not automatically a Frankfurt-only deployment. The key issue is hidden in the model identifier: the widely cited eu.anthropic.claude-sonnet-4-5-20250929-v1:0 profile can process an invocation in several AWS EU regions, while the submitted SecNews configuration presents it as a single-region Frankfurt answer. SecNews is right on the most consequential Microsoft point. Microsoft’s current documentation says Anthropic models used within Microsoft 365 Copilot, Copilot Studio, Researcher, Power Platform, and certain Microsoft 365 app experiences are excluded from the EU Data Boundary and, where applicable, in-country processing commitments. That makes Anthropic-backed Copilot a configuration requiring deliberate approval by a Greek organization, not an interchangeable replacement for the default Microsoft-hosted Copilot experience.
But the article’s larger conclusion — that Bedrock Frankfurt is the only unambiguous GDPR and DORA route — goes beyond what the records support. Bedrock offers useful technical controls, including private endpoints, detailed AWS logging, configurable retention modes, and an EU-only geographic inference option. Those controls improve an organization’s ability to document and restrict a deployment. They do not turn a model endpoint into a pre-certified DORA solution, nor does selecting eu-central-1 alone establish that every inference occurred in Frankfurt.
For Greek banks, insurers, payment institutions, investment firms, and other financial entities in DORA’s scope, the practical answer is more exacting: keep Microsoft 365 Copilot for ordinary Microsoft 365 productivity where its tenant controls and EU Data Boundary commitments fit the workload; use Claude through Bedrock only after choosing the inference-routing mode, retention policy, data flow, and contractual evidence appropriate to each regulated use case.

Infographic contrasts Microsoft 365 Copilot’s EU data risks with a secure Frankfurt Claude cloud region.Microsoft’s Anthropic Option Has a Clear EU Boundary Exception​

Microsoft’s official position is unusually direct. Microsoft 365 Copilot is covered by its commercial customer privacy, security, GDPR, and EU Data Boundary commitments, and Microsoft says customer prompts, responses, and Microsoft Graph data are not used to train its foundation models. It also says Copilot respects existing identity permissions, sensitivity labels, retention policies, and audit controls.
That is important for organizations already managing documents, mailboxes, Teams messages, and SharePoint permissions through Microsoft Purview and Entra ID. Copilot does not invent a new authorization model; it operates through the permissions the tenant already has. The risk is therefore often excessive access already present in SharePoint sites, broad Teams memberships, or poorly maintained shared mailboxes — problems Copilot can expose at speed.
Anthropic models are a separate case. Microsoft says they are currently outside the EU Data Boundary. EU, EFTA, and UK customers have Anthropic models disabled by default at the broad subprocessor level, though administrators can opt in. Microsoft also introduced a separate setting during 2026 allowing Anthropic models in certain Copilot experiences in Word, Excel, and PowerPoint for EU, EFTA, and UK tenants.
The distinction is not cosmetic. If a Greek tenant enables Anthropic as a Microsoft subprocessor, it needs to document the transfer and processing arrangement rather than assume that the Microsoft 365 tenant’s ordinary EU data location applies unchanged. Microsoft’s Data Protection Addendum and enterprise data-protection commitments still matter, but they are not the same thing as an EU Data Boundary commitment for the Anthropic inference itself.
Organizations should also separate this decision from generic Copilot use. A Microsoft 365 Copilot deployment using Microsoft-supported models can remain an EU Data Boundary service for an eligible EU tenant. Turning on an Anthropic model option changes the data-path analysis for only the experiences using that provider; it does not make all Copilot activity non-compliant.

The Bedrock Model ID Is the Residency Control That SecNews Missed​

AWS Bedrock can provide a stronger and more inspectable architecture for a custom Claude application than a browser session at claude.ai or an Anthropic option inside a productivity suite. AWS states that Bedrock model providers do not have access to Bedrock deployment accounts, service logs, customer prompts, or completions under its normal service design. It also supports VPC interface endpoints through AWS PrivateLink, allowing workloads inside a VPC to call Bedrock without a public IP address, internet gateway, or NAT device.
Those are meaningful implementation advantages. They allow a firm to place application logic, retrieval systems, IAM roles, CloudTrail records, security monitoring, and model calls inside an AWS account it administers. Bedrock Guardrails can detect or mask supported sensitive information and can use custom regular expressions for values such as Greek tax identifiers, AMKA patterns, and IBANs.
The location claim needs a correction, however. AWS lists Claude Sonnet 4.5 as available through an EU geographic cross-region inference profile. Requests using the eu.-prefixed model ID from Frankfurt may be handled in Frankfurt, Stockholm, Milan, Spain, Ireland, or Paris. They remain within the designated AWS EU geography, which may meet an organization’s EU residency requirement, but they are not guaranteed to remain in eu-central-1.
That is especially relevant because the sample code supplied by SecNews uses the EU geographic profile rather than a Frankfurt-only direct model identifier. The configuration therefore contradicts the article’s stated goal. A firm requiring strict single-region processing must verify that the chosen Claude model is available through an in-region deployment in eu-central-1, use the direct regional model ID rather than the eu. geographic profile, and block unapproved inference profiles through IAM and service-control policies.
An EU geographic profile is not a bad choice. It is often the better resilience and capacity choice, because it permits AWS to route within EU regions during demand spikes. But it must be described accurately in a DPIA, supplier register, architecture diagram, and internal data-flow record. “EU-only” and “Frankfurt-only” are different compliance assertions.

Zero Retention Must Be Set and Tested, Not Assumed​

The SecNews guidance also overstates the default retention story. AWS now documents multiple Bedrock data-retention modes. A none setting provides zero data retention: request and response data are not written to durable AWS storage or shared with the model provider. But a default mode follows the model’s own retention conditions, and AWS says some models can retain content for safety or abuse prevention.
For a DORA-regulated workload, the correct control is a policy decision backed by enforcement. Set the account or project to zero retention where the selected model permits it, then use IAM controls that deny any configuration change to a different retention mode. Test the behavior with a non-production account and capture the evidence. A statement in an architecture document that “Bedrock retains nothing” is not a substitute for verifying the setting actually applied to the model in use.
Retention also has a routing consequence. AWS says that where cross-region inference is used and data is retained, the retained inputs and outputs are stored in the destination region that processed the request. That makes the inference profile and the retention policy inseparable. A firm cannot claim a Frankfurt storage posture if it deliberately permits regional routing and retains inference data.
The proposed CloudTrail-to-S3 logging design deserves similar care. CloudTrail records management and API activity; it should not be treated as an audit copy of prompts and answers unless an application separately records them. Storing full prompts and outputs for five years in immutable S3 could create a larger sensitive-data repository than the LLM service itself. DORA requires appropriate logging, monitoring, resilience, testing, and third-party risk controls; it does not impose a universal five-year prompt-retention rule for every AI use case.
Use immutable logs for deployment events, policy changes, identity activity, inference metadata, and security-relevant application events. Retain full content only when a specific legal, supervisory, or business requirement justifies it, with a defined retention period, access control, encryption, and deletion procedure.

DORA Does Not Approve Claude, Copilot, or AWS​

DORA has applied since January 17, 2025, and it governs financial entities’ digital operational resilience and their use of ICT third-party providers. It does not designate AWS Bedrock, Anthropic Claude, Microsoft 365 Copilot, or any other model service as compliant by default.
A Bedrock deployment can make the required work more tractable because the firm can control networking, cryptographic keys for data it stores, access roles, logs, and model selection within one cloud account. Microsoft 365 Copilot can also be used within a DORA program, particularly where it is a managed enterprise service already covered by the organization’s Microsoft supplier controls. Neither choice eliminates the requirement to assess the service, record the contract, manage subcontractors, establish exit arrangements, test incident response, and evaluate concentration risk.
The register of information is a concrete example. Commission Implementing Regulation 2024/2956 establishes the standardized templates that financial entities use for DORA’s register of contractual arrangements. A firm using Claude through Bedrock may need to document AWS as the contracted ICT service provider, identify material subcontracting and the model-provider role where applicable, and map the actual services used: Bedrock, VPC, PrivateLink, S3, KMS, CloudTrail, GuardDuty, identity services, and any retrieval or data-integration component.
The submission’s incident-reporting timeline also needs qualification. DORA’s detailed reporting rules apply to major ICT-related incidents and are implemented through regulatory technical standards. An organization should not turn every model error, guardrail block, or ambiguous output into a statutory DORA incident. It needs an AI-specific incident playbook that distinguishes model-quality failures, data protection events, availability incidents, security events, and reportable major ICT incidents under the applicable supervisory rules.

A Defensible Greek Deployment Has Two Lanes​

The sensible pattern for many Greek organizations is not “Claude versus Copilot.” It is a governed split between off-the-shelf productivity AI and a custom, controlled model platform.
Microsoft 365 Copilot is appropriate for low- and medium-sensitivity work where the tenant’s information governance has already been cleaned up: drafting in Word, meeting and email summaries, Excel assistance, internal knowledge retrieval limited by existing user permissions, and presentation preparation. Before rollout, administrators should review SharePoint oversharing, guest access, sensitivity labels, retention policies, web-search settings, and the separate switch governing Anthropic models.
Bedrock is appropriate where the organization needs a purpose-built workflow: controlled contract analysis, policy comparison, complaint triage, regulated document summarization, or a tightly scoped internal assistant. The workload should begin with data classification and a DPIA, identify whether special-category or financial data is actually necessary, minimize the prompt, and put human approval between the model and a customer, credit, insurance, investment, or compliance decision.
A financial entity should insist on these evidence-producing controls:
  • Use an in-region model deployment when the policy requires Frankfurt-only processing, or document the permitted EU destinations when using an EU geographic inference profile.
  • Enforce the intended Bedrock retention setting through account policy and test it whenever a model, API, or project configuration changes.
  • Route API traffic through PrivateLink, while recognizing that this protects the connection from the customer VPC to AWS rather than making Bedrock an on-premises service.
  • Treat Guardrails as a preventive layer, not proof that personal data cannot reach a model, because pattern matching and probabilistic detection can miss content or behave differently with tool-call outputs.
  • Maintain a tested exit plan that covers the application’s prompts, retrieval indexes, IAM policies, logging, evaluation suite, and alternative-model validation rather than merely naming Llama or Mistral as theoretical substitutes.
AWS Outposts does not change this final point. Outposts can place certain AWS infrastructure on a customer site, but it does not make Amazon Bedrock inference a local, on-premises Claude service. Anthropic’s closed models are not available for customer-operated on-premises inference.
For a Greek financial firm, the immediate action is to audit every Copilot and Bedrock model selection already in use. If the Bedrock application calls an eu. inference profile, record it as EU geographic processing, not Frankfurt-only processing. If Microsoft 365 Copilot’s Anthropic option is enabled, treat it as an explicit EU Data Boundary exception. Those two checks will expose whether the organization’s documented AI controls describe the system it actually runs.

References​

  1. Primary source: secnews.gr
    Published: 2026-08-04T13:13:50+00:00
  2. Related coverage: learn.microsoft.com
  3. Related coverage: learn.microsoft.com
  4. Related coverage: docs.aws.amazon.com
  5. Related coverage: docs.aws.amazon.com