Running Business Apps in Your Own Cloud Tenant: Access, Data Location, and Personal Data

Hello, this is Ryuta Hamamoto from TIMEWELL.

This series has been about one decision: cancelling an expensive SaaS subscription and owning the business app yourself. I have written about how to decide, how to tell which systems are safe to build, how to model five-year costs, and how to run the cancellation and migration. This fifth and final piece takes on the question that is left once all of that is settled. Where should the rebuilt app live?

Here is my answer up front. If you have decided to own the app, it usually runs better inside the cloud environment your company already contracts for, what I will call your own tenant in this article. You can line it up with your identity platform and access groups, connect it to the data you already hold, and keep the audit logs yourself. But moving the app also moves two other things: how personal data is classified under Japan's privacy law, and who carries the operational load. Choosing a Tokyo region does not settle either one. This piece is for IT teams, security and privacy leads, and whoever runs your ISMS office, and it covers the benefits and the costs with primary sources. If you want to start with whether to cancel at all, begin with the series hub on decision criteria.

How multi-tenant SaaS differs from your own tenant

Start with the terms. NIST SP 800-145, the definition of cloud computing most people cite, lists resource pooling as an essential characteristic: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model¹. The same document says that with SaaS, the consumer does not manage or control the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific configuration settings. In practice, a settings screen is about all a SaaS customer controls.

By your own tenant, I mean placing the business app and its data as your own asset inside the account your company holds with a cloud platform such as AWS, Microsoft Azure, or Google Cloud. The platform itself is shared infrastructure run by the cloud provider, but you are the one administering the app, owning the data, and handing out permissions. That is different from single-tenant SaaS, where a vendor stands up a dedicated environment for each customer. Even in a dedicated environment, if the vendor runs it, the keys to the app and the data stay with the vendor.

AWS publishes design guidance for companies that build SaaS, the Well-Architected SaaS Lens. It calls the shared model "pool" and the per-tenant model "silo," and lays out the trade-offs of each²³. The downsides it lists for pool are noisy neighbors, where one tenant's load affects others; the difficulty of tracking cost per tenant; a wider scope of impact ("an outage will likely impact all the tenants in your system"); and compliance pushback where rules impose strict constraints on the accessibility and isolation of resources. Silo is the mirror image. It handles isolation requirements and limits the blast radius, but it costs more and makes it harder to roll changes out to every tenant at once. The guidance is written for SaaS builders, yet reading it from the customer side tells you what your vendor traded away to give you the price you pay.

Aspect	Multi-tenant SaaS	Vendor-run dedicated SaaS	Your own tenant
Who runs the platform and app	Vendor	Vendor	You, or a party you engage
Accounts and permissions	A separate admin console per service	A separate admin console per service	Aligned with your identity platform
Audit logs	Vendor decides what is exposed and for how long	Same	You choose where logs go and how long they stay
Timing of changes	Vendor decides	More room to negotiate	You decide
Blast radius of an outage	Can go down with other customers	Usually contained to your environment	Usually contained to your environment
Operations, monitoring, patching	Mostly the vendor	Mostly the vendor	You
Cost shape	Scales with seats or usage	Tends to cost more	Cloud usage plus the people who run it

The last two rows are the costs I cover later. Think of your own tenant as gaining on the first five rows and paying on the last two.

What runs better in your own tenant

When I say it "runs better," I mean four things.

First, identity and permissions line up. If you use ten SaaS products, you have ten admin consoles and ten permission models. Every hire, transfer, and departure means fixing accounts in each one, and sooner or later someone gets missed. In your own tenant, you can grant access by the same groups your identity platform already uses. AWS IAM Identity Center, for example, lets you connect an existing identity provider and synchronize users and groups from your directory⁴. Once a transfer lands in the HR data, the app permissions follow the same path. That single source also makes access reviews much easier to explain during an internal ISMS audit.

Second, it connects to the data you already have. Quote registers, internal FAQs, approval records. If that data sits in the same tenant, you can connect it without routing through someone else's API. When you link SaaS products to each other, what you can sync and how often usually depends on the vendor's API and pricing tier, and some data only comes out on a higher plan. I wrote about how to pick which systems to own in the second article in this series. My sense is that the best candidates are exactly the ones whose value appears only when they connect to other data.

Third, you keep the audit logs. Who did what, to which data, and when. With SaaS, the vendor decides how much of that record you can see and how long it lasts. In your own tenant, you decide where it is stored and for how long. AWS CloudTrail records actions taken by users, roles, and AWS services as events, and its event history, available without any setup, covers the past 90 days of management events⁵. If you want more than 90 days, you configure where to keep it. Put the other way: do nothing, and the history disappears after 90 days. That is one of the things you settle in the design.

Fourth, you are less exposed to the vendor's changes. With SaaS, screen redesigns, retired features, repackaged plans, and revised terms arrive on the vendor's schedule. Japan's Civil Code allows a party that uses standard terms to change them without individual consent when the change serves the other party's general interest, or when it is reasonable in light of its necessity, the appropriateness of the new terms, and other circumstances (Article 548-4)⁶. Whether a given B2B SaaS agreement counts as standard terms is a case-by-case question, but it is safer to read any subscription on the assumption that the other side can change it. With an app in your own tenant, you choose when things change. The cloud platform will still retire runtimes and the like, so you have fewer parties pushing changes on you, not none.

All four come from the same root: the app and its data live in the same place as the rest of your systems. If you are going to rebuild something you used to rent, designing where it lives is part of what makes the rebuild worth doing. That is the reasoning behind my view.

Is it an entrustment? It depends on who can touch the data

Now the personal data question. In my experience this is where most of the misunderstandings live.

A quick primer for readers outside Japan. Japan's Act on the Protection of Personal Information (APPI) generally requires consent before a business provides personal data to a third party. One exception is entrustment: when you entrust another business with handling personal data on your behalf, no consent is needed, but you must supervise that business (Article 25). Japan's regulator, the Personal Information Protection Commission (PPC), publishes a Q&A on its APPI guidelines, and several answers deal directly with cloud services.

Q7-53 says the test for whether using a cloud service is a consent-requiring provision or an entrustment is not whether the stored data includes personal data, but whether the cloud provider is set up to handle that personal data⁷. The example it gives of a provider that is not set up to handle it: the contract states that the provider will not handle the personal data stored on its servers, and access is properly controlled. In that case nothing has been provided, so you need neither consent nor Article 25 supervision. Practitioners in Japan sometimes call this the "cloud exception."

Q7-54 immediately adds a caveat. Even when there is no provision, the business using the service must take appropriate security control measures "as part of the security control measures it must carry out itself"⁸. The duty to supervise a vendor goes away; the work you owe on your own side does not.

So what about SaaS? On March 25, 2024, the PPC issued an alert after finding that a cloud service provider was itself a personal information handling business acting as an entrusted party⁹. A business system the provider offered was hit by unauthorized access, and personal data about the employees of clients of the many companies using it was encrypted. The Commission cited three factors. The terms of use allowed the provider to monitor, analyze, and investigate data when it judged that necessary for maintenance or operations. The provider held a maintenance ID that could reach customers' personal data, with no technical access controls to prevent handling. And the provider had in fact handled that data after exchanging confirmation documents with customers. The alert asks users to make the agreed security measures "as objectively clear as possible" in terms or contracts and to verify them, for example through regular reports. Because the vendor operates the app, SaaS tends to be built so that the vendor can reach customer data through maintenance or support. I read the alert as the regulator putting that on record.

This is the point you cannot skip when you consider your own tenant. The Q7-53 test is not about where the data sits. It is about who handles it. It follows that even in your own tenant, if an outside developer or maintenance vendor can touch production personal data, that relationship should be treated as an entrustment. The Q&A does not address this scenario directly; this is my reading, applying the Q7-53 test and the factors in the alert. But an outside vendor who can see production data through a maintenance ID is in much the same position as the provider in that case. That includes an FDE (Forward Deployed Engineer, an engineer who works on site with the customer to build things) like us, if we take on maintenance.

Setup	Can an outside party touch the data?	Likely classification (general)	What stays with you
Multi-tenant SaaS	Yes, through maintenance or support	Often an entrustment	Supervising the vendor (Article 25) and making terms explicit
Own tenant, operated only by your staff	The platform provider is contractually barred and access-controlled	Can be treated as neither provision nor entrustment (Q7-53)	Your own security control measures (Q7-54)
Own tenant, outside vendor maintains it with production data	Yes	Treat as an entrustment	Supervising the vendor and logging its access
Own tenant, outside vendor builds with masked data and has no production access	Designed so it cannot	May be possible to keep outside entrustment	Maintaining the permission design and the evidence for it

The 2026 amendment to the APPI matters here too. Passed on July 10, 2026 and promulgated on July 17, it adds an explicit duty for any business entrusted with handling personal information not to handle it beyond what is necessary to carry out the entrusted work¹⁰¹¹. It also creates a mechanism for cases where the entrusted party does not decide how the data is handled, such as mechanically processing data exactly as instructed. If the contract fixes every aspect of how the data is handled and the parties agree on measures that let the entrusting business track what happens, such as prompt reporting of any leak, the entrusted party is in principle exempted from the APPI obligations it would otherwise carry as a handling business. The duty not to exceed the necessary scope and the security control duty still apply. The amendment takes effect within two years of promulgation, and the details are still being worked out in cabinet orders and Commission rules. Whether work that involves the vendor's own judgment, such as maintenance, can qualify for the exemption is something to confirm once the rules are in place.

The direction is clear, though. What you write into an entrustment contract, what data is handled and how, and how you will know what is happening, is going to carry more weight. If you bring an outside maintenance vendor into your own tenant, putting that language in the contract now should save you a scramble when the amendment takes effect.

All of this is general guidance. Whether a particular setup is an entrustment is something to confirm with your legal team or outside counsel.

Choosing a Japanese region still leaves work to do

I often hear that keeping data in a Japanese region makes it safe. I think that is half right and half misleading.

The right half first. In the cloud, you can choose where data is stored at the level of a country or region. NIST's definition notes that customers generally have no control or knowledge over the exact location of resources but may be able to specify location at a higher level of abstraction, such as country, state, or datacenter¹. AWS has two regions in Japan: Tokyo, with four Availability Zones, and Osaka, with three¹².

The misleading half is in the PPC's Q10-25¹³. When you use a cloud service provided by a business in a foreign country, even if that provider is not set up to handle the personal data, you are still "handling personal data in a foreign country," so you must understand that country's personal information regime and then take security control measures. The answer goes on: "The same applies where personal data is stored on servers located in Japan." As part of disclosing your security measures, you must also make available to individuals the name of the foreign country where the provider is located, the name of the foreign country where the servers are located, and the measures you took after understanding that country's regime. Storing data on a foreign server is not itself a provision to a third party in a foreign country (Article 28) if the provider does not handle it, but the need to understand the foreign regime remains (Q12-3)¹⁴.

So choosing the Tokyo region does not remove the work of understanding the foreign rules if your cloud provider is a foreign company. What the region choice mainly changes is one line in your disclosure: the country where the servers sit. "We kept it in Japan, so there is nothing to explain" is not how this works.

Generative AI adds another layer, because where data is stored and where a model processes a request are two different things. Amazon Bedrock, for example, can route inference requests across regions, and you can choose between a profile tied to a specific geography, such as the US or the EU, and a global profile that can route to any commercial region worldwide¹⁵. AWS's own guidance says to choose a geographic profile when you have data residency requirements, and that the global profile, which has no geographic restriction, is roughly 10 percent cheaper. Your data can be stored in Tokyo while inference runs wherever the setting allows.

So how should you design it? My advice is not to hard-code a single region from day one, but to design so the region can be chosen per requirement. Data that a contract or industry rule requires to be processed in Japan gets a setting that keeps processing in Japan. Other data gets whatever model and processing location give the right balance of accuracy and cost. Record which choice you made, and keep it consistent with your privacy disclosures and internal records. Our FDE work follows the same approach: we do not restrict the processing region across the board.

Before the region question, check something else: whether the data you send will be used to train a model. We only choose services and models where the terms of use, the contract, or a configuration setting confirms that customer data is not used for training, and we record what we relied on. The place to confirm this is what the cloud provider or model provider itself says. AWS, for example, states in its Bedrock FAQ that neither AWS nor third-party model providers use inputs to or outputs from Bedrock to train models¹⁶. Keeping statements like that in your records as the basis for each choice makes the conversation with auditors much shorter.

Operational responsibility moves to you, so decide it in the design

I have spent most of this article on the benefits. Now for what you pay.

The clearest way to frame cloud responsibilities is the AWS shared responsibility model¹⁷. AWS is responsible for security "of" the cloud: the hardware, software, networking, and facilities. The customer is responsible for security "in" the cloud, and how much that covers depends on which services you choose. Pick an IaaS service like Amazon EC2, and the guest operating system, including updates and security patches, the application software on top, and the configuration of the security group firewall are all yours. It is safest to assume that anything the SaaS vendor used to handle becomes your job the moment the app moves into your own tenant.

Task	Under SaaS	In your own tenant	How to reduce the load
OS and middleware patching	Vendor	You	Use managed or serverless services so there is less to patch at all
Monitoring and incident response	Vendor	You	Decide up front what to monitor and who gets called, and spell out night-time coverage
Backup and restore	Vendor (scope depends on the terms)	You	Put restore tests on the annual calendar instead of just taking backups
Account and access reviews	Done separately per service	Done once through your identity platform	Match the review cycle to your internal ISMS audit
Audit log retention	Whatever the vendor exposes	You	Decide where logs go, how long they stay, and who can read them
Vulnerabilities in the app code	Vendor	You	Build review and automated scanning into the development flow
Data deletion	Vendor deletes on cancellation	You	Write retention periods and deletion steps into the design documents

If you run an ISMS office, look at how the controls map as well. ISO/IEC 27001:2022, adopted in Japan as JIS Q 27001:2023, added 11 new controls, among them 5.23 information security for use of cloud services, 8.10 information deletion, 8.16 monitoring activities, and 8.28 secure coding¹⁸. While you were on SaaS, 5.23 was mostly about how you selected and used the SaaS. Once the app moves into your own tenant, 5.23 shifts to how you use the cloud platform, and 8.16 monitoring and 8.28 secure coding land on your side as your own work. Your Statement of Applicability may need an update. I wrote an overview of ISMS in the ISO/IEC 27001 beginner's guide.

Control 8.28 carries more weight now that code is often written with generative AI. In a user study presented at ACM CCS 2023, researchers at Stanford University found that participants with access to an AI assistant wrote significantly less secure code than those without, and were more likely to believe their code was secure¹⁹. Those results come from an older model, so they may not carry over directly to today's tools. Even so, I would not let speed become the reason to skip human review of AI-written code.

Control 8.10 shows up again during migration. Confirming that data left in the cancelled SaaS has actually been deleted, and building a way to delete expired data in the new app, are two separate jobs. I covered the first in the article on cancellation and migration, and how to compare costs including the people who run the system in the five-year cost model. The mistake I most want you to avoid is concluding that building is cheaper than SaaS without pricing in the cost of running it in your own tenant.

What our FDE service can do

Here is how our FDE work takes this on. An FDE goes on site, watches how the work is actually done, and builds something that runs. We see cancelling SaaS and bringing the work in-house as a job FDEs can carry out in practice. The full picture is on the FDE service page.

The first step, before deciding where anything lives, is an inventory. Which SaaS products to cancel and own instead. Where each workflow's data comes from and where it goes. Where the personal data is. We write that down before starting on the design.

Then comes the tenant design: how accounts are split, how the app connects to your identity platform, the permission model, where audit logs go and for how long, and backup and restore testing. The region is chosen per requirement, and we record which data needs processing in Japan and which does not. If generative AI is part of the app, we choose, as described above, only services and models where we can confirm customer data is not used for training, and keep the evidence.

Development runs on data with personal information and other sensitive fields masked. Any feature that writes back to a production business system waits until four conditions are in place: permissions, a pre-execution simulation, human sign-off on significant decisions, and an audit trail. If we need to take on maintenance that touches production personal data, we treat it as an entrustment and put the scope of handling, how access happens and is logged, and how a leak is reported into the contract. TIMEWELL holds ISO/IEC 27001 certification (scope: planning, development, and provision of SaaS products using AI technology).

Engagements are time-boxed at 45 to 90 days. The exit condition is that your own team can run the system without us. Patching procedures, access reviews, and restore tests are all included in that period, up to the point where your people can do them on their own. I also wrote about where to draw the line between what you do in-house and what you hand off in How Far to Insource AI.

How this differs from contract development

A contract developer can build an app in your own tenant too. The differences are how hours are treated, where the learning goes, and how the engagement ends.

In contract development, hours are revenue. The longer maintenance goes on, the more the vendor earns, so a design that leaves operations with the vendor is a natural choice for them. The app you put in your own tenant ends up as something only the outside maintenance vendor can touch, and the supervision of an entrusted party goes on indefinitely. That is not independence from SaaS. It is the same dependence, moved to a different vendor.

Our FDE work treats hours as investment. The goal is for on-site hours per customer to go down, and the engagement ends once your team runs things on its own. Mechanisms that other companies can use go back into our product, so the next customer benefits from day one, while your specific settings and business data stay yours. Putting the app in your own tenant fits that way of ending well. The app and the data are in your environment from the start, so when we leave, there is nothing to carry out. I went into how FDE differs from other kinds of support in How FDE Differs from AI Accompaniment.

What we do in practice, and where it falls short

Let me be direct. Your own tenant is not the right home for every company.

It is hard to recommend to a company with nobody to run it. The tasks in the table above recur every month after launch. If there is no one in-house who can handle operations, and no one you are willing to hand them to, staying on SaaS or using a vendor-run dedicated environment may suit you better. We will say so plainly at the first conversation.

If you choose a setup where we keep doing maintenance, the entrustment relationship continues, and so does your supervision work. Self-sufficiency is our exit condition, but some tasks, such as overnight incident response, can be hard to cover in-house. In that case, let's talk about a separate maintenance contract with a limited scope. That contract will also spell out the scope of data handling.

We do not restrict the processing region across the board. Where processing in Japan is mandatory, we agree on it in the individual contract and reflect it in the price. We confirm this at the start so no one assumes that hiring us automatically means processing in Japan.

We are not a law firm. Final decisions on whether something is an entrustment, or how far you need to understand a foreign regime, rest with your legal team or outside counsel. What we can provide is what they need to decide: architecture diagrams, access paths, and records. As for ISO/IEC 27001, the scope is as stated above, and we will not describe it in a way that suggests the certification extends to the individual work we do in your tenant.

Finally, capacity. We are a small company, and there is a limit to how many sites we can work at once.

Summary

For a business app you have decided to own, my view is that your own tenant is usually the better home. You can align it with your identity platform and access groups, connect it to your existing data, keep the audit logs yourself, and decide when things change.

In exchange, you take on two things. One is personal data. Whether something is an entrustment under the APPI depends on who handles the data, not where it is stored. If an outside developer or maintenance vendor can touch production data, treat it as an entrustment. If you design it so they cannot, back that up with the permission design and the evidence. And a Japanese region does not remove the need to understand the rules of the country your cloud provider comes from. The other is operations: patching, monitoring, backups, and deletion become your job.

If you do one thing on Monday, take the SaaS you are thinking of cancelling and check, in the contract and the terms, who on the vendor's side can reach your data and with which ID. If the answer is unclear, that alone is a reason to look at your own tenant.

If you want to design your own tenant and move to it with an FDE, take a look at the FDE service page or book a consultation about FDE. To read the series from the start, begin with the decision criteria.

Footnotes

1. NIST Special Publication 800-145, The NIST Definition of Cloud Computing (NIST, September 2011). The definitions of resource pooling, SaaS, and private cloud are from this document ↩ ↩²

2. Pool isolation (AWS Well-Architected, SaaS Lens). The pros and cons of the pool model (noisy neighbor, tenant cost tracking, increased scope of impact, compliance pushback) are from this page ↩

3. Silo isolation (AWS Well-Architected, SaaS Lens) ↩

4. What is IAM Identity Center? (AWS IAM Identity Center User Guide) ↩

5. What Is AWS CloudTrail? (AWS CloudTrail User Guide). The 90-day event history of management events is described on this page ↩

6. Civil Code (Act No. 89 of 1896), Article 548-4 (changes to standard terms). e-Gov statute database, in Japanese ↩

7. Q&A on the Guidelines for the Act on the Protection of Personal Information, Q7-53 (Personal Information Protection Commission). In Japanese; quotations are the author's translation ↩

8. Same Q&A, Q7-54 (Personal Information Protection Commission). In Japanese ↩

9. Points to note when a cloud service provider is a personal information handling business under the APPI (alert) (Personal Information Protection Commission, March 25, 2024). In Japanese ↩

10. On the Act Partially Amending the Act on the Protection of Personal Information (PPC Secretariat, July 2026). The changes for entrusted parties are on page 12; the new provision is Article 30-3. All related materials are listed on the PPC's 2026 amendment page. In Japanese ↩

11. The Commission's next steps following passage of the amendment act (PPC Secretariat, July 31, 2026). Passage on July 10, 2026 and promulgation on July 17 are stated in this document. In Japanese ↩

12. AWS Regions (AWS Global Infrastructure documentation). ap-northeast-1 (Tokyo) has four Availability Zones and ap-northeast-3 (Osaka) has three (checked September 29, 2026) ↩

13. Q&A on the Guidelines for the Act on the Protection of Personal Information, Q10-25 (Personal Information Protection Commission, added September 2021). In Japanese; quotations are the author's translation ↩

14. Same Q&A, Q12-3 (Personal Information Protection Commission, updated September 2021). In Japanese ↩

15. Route model inference requests across AWS Regions with cross-Region inference (Amazon Bedrock User Guide). The difference between geographic and global profiles and the roughly 10 percent savings are from this page (checked September 29, 2026) ↩

16. Amazon Bedrock FAQs (AWS). The statement that inputs and outputs are not used for training is in the security section (checked September 29, 2026) ↩

17. Shared Responsibility Model (AWS) ↩

18. ISMS User's Guide for JIS Q 27001:2023 (ISO/IEC 27001:2022), JIP-ISMS111-4.0 (JIPDEC, March 31, 2025). The 11 added controls are in Table A-2 on page 74. In Japanese ↩

19. Neil Perry, Megha Srivastava, Deepak Kumar, Dan Boneh, "Do Users Write More Insecure Code with AI Assistants?" (arXiv:2211.03622, ACM CCS 2023) ↩