Who is the Controller and who is the Processor if Company X hosts/embeds content of Company Y
<p>Let's say we have two companies "WeServe" and "OurContent" and the following relationships, who is the Controller and who is the Processor or are they Joint Controllers (<a href="https://gdpr-info.eu/art-26-gdpr/" rel="nofollow noreferrer">Art. 26 GDPR</a>) or is there another kind of relationship or none at all?</p>

<ol>
<li>The most common case, <code>ourcontent.com</code> is hosted by WeServe. OurContent is the Controller and WeServe the Processor, OurContent has a Privacy Policy and needs a DPA from WeServe</li>
<li><code>ourcontent.weserve.com</code> or <code>weserve.com/ourcontent</code> with 100% of the content provided by OurContent. Still the same as #1, apart from WeServe being visible in the url, I suppose.</li>
<li>OurContent uploads content to WeServe and is part of some page of WeServe and it may not be obvious content is provided by OurContent and OurContent does not access or process any user data.</li>
<li>OurContent uploads content to WeServe and is part of some page of WeServe but processes some user data on its own.</li>
<li>WeServe crawls the internet and copies and hosts content of OurContent that processes some user data. OurContent doesn't necessarily mind this and may even see this as beneficiary. (similar to the wayback machine of archive.org)</li>
<li>OurContent provides a url to WeServe which will be embedded in an iframe as part of a page of WeServe.</li>
<li>WeServe embeds pages of OurContent in an iframe in its own pages. (e.g. Google Translate).</li>
</ol>

<p>If WeServe and OurContent are Joint Controllers, is it sufficient if both of them have their own privacy policy with a contact point for data subjects or do they need an extra arrangement that combines both privacy policies in an appropriate way?</p>

<p>It is a very difficult question, but I'll try to answer anyway.</p>

<blockquote>
  <ol>
  <li>The most common case, ourcontent.com is hosted by WeServe. OurContent is the Controller and WeServe the Processor, OurContent has a Privacy Policy and needs a DPA from WeServe</li>
  <li>ourcontent.weserve.com or weserve.com/ourcontent with 100% of the content provided by OurContent. Still the same as #1, apart from WeServe being visible in the url, I suppose.</li>
  <li>OurContent uploads content to WeServe and is part of some page of WeServe and it may not be obvious content is provided by OurContent and OurContent does not access or process any user data.</li>
  <li>OurContent uploads content to WeServe and is part of some page of WeServe but processes some user data on its own.</li>
  <li>WeServe crawls the internet and copies and hosts content of OurContent that processes some user data. OurContent doesn't necessarily mind this and may even see this as beneficiary. (similar to the wayback machine of archive.org)</li>
  <li>OurContent provides a url to WeServe which will be embedded in an iframe as part of a page of WeServe.</li>
  <li>WeServe embeds pages of OurContent in an iframe in its own pages. (e.g. Google Translate).</li>
  </ol>
</blockquote>

<ol>
<li>OurContent is the controller, and WeServe is a processor, as you said, because WeServe is processing personal data on your behalf.</li>
<li>Same as number 1, provided that the situation is exactly the same (OurContent actually collects the data, and WeServe just hosts it).</li>
<li>If OurContent really doesn't collect or process any personal data, then they are nothing, neither a controller nor a processor. If WeServe processes personal data for their own private purposes (for example tracking visitors) then they are a controller. Users will visit your content on WeServe, but they will just have to accept WeServe's privacy policy. </li>
<li>OurContent is a controller, and WeServe is a processor of personal data on behalf or Ourcontent (so it's the same situation as number 1). However, if WeServe also processes personal data for their own private purposes (for example tracking visitors), then they would also be a controller. I'm not sure whether they would be a separate controller or a joint controller though.</li>
<li>OurContent is a controller. WeServe is also a controller, and definitely a separate controller. I really don't think that blocking crawlers and bots is required by the GDPR, as that would mean totally changing the way the internet works. So, any crawler or bot is free to browse the internet, as long as they comply with the GDPR. And whether they comply or not is their own business, I guess.</li>
<li>(or 7) I don't really understand the difference between point 6 and point 7, in both cases it sounds like WeServe is embedding an iframe from OurContent. Speaking of iframes in general, they should be treated like separate pages that open up automatically. The privacy issues arise when the "automatically opened page" (the iframe) also collects personal data and the visitor does not expect it. The visitor is automatically sending the IP to the page in the iframe, but they could also be sending a cookie and other data. So the main site is a controller, and the iframed side is also a controller, they are separate. However, the main site can't let its visitors send personal data to another controller without consent, so most iframes should be blocked by default.   </li>
</ol>

privacy european-union gdpr