美國聯邦貿易委員會插手企業資訊安全引起爭議
美國聯邦貿易委員會(Federal Trade Commission, FTC)於2013年8月29日對位於亞特蘭大的一家小型醫療測試實驗室LabMD提出行政控訴，指控LabMD怠於以合理的保護措施保障消費者的資訊（包括醫療資訊）安全。FTC因此依據聯邦貿易委員會法(Federal Trade Commission Act, FTC Act)第5條展開調查，並要求LabMD需強化其資安防護機制（In the Matter of LabMD, Inc., a corporation, Docket No. 9357）。
根據FTC網站揭示的資訊，LabMD因為使用了點對點（Peer to Peer）資料分享軟體，讓客戶的資料暴露於資訊安全風險中；有將近10,000名客戶的醫療及其他敏感性資料因此被外洩，至少500名消費者被身份盜用。
不過，LabMD反指控FTC，認為國會並沒有授權FTC處理個人資料保護或一般企業資訊安全標準之議題，FTC的調查屬濫權，無理由擴張了聯邦貿易委員會法第5條的授權。
本案的癥結聚焦於，FTC利用了對聯邦貿易委員會法第5條「不公平或欺騙之商業行為(unfair or deceptive acts)」的文字解釋，涉嫌將其組織定位從反托拉斯法「執法者」的角色轉換到（正當商業行為）「法規與標準制訂者」的角色，逸脫了法律與判例的約束。由於FTC過去曾對許多大型科技公司（如google）提出類似的控訴，許多公司都在關注本案後續的發展。
世界衛生組織（World Health Organization, WHO）於2020年8月24日公布「COVID-19疫苗全球取得機制（COVID-19 Vaccines Global Access Facility, COVAX）」，由全球疫苗與預防注射聯盟（Global Alliance for Vaccines and Immunisation, GAVI）、流行病預防創新聯盟（Coalition for Epidemic Preparedness Innovations, CEPI）及WHO共同主導，與多家疫苗廠商合作，協助取得多種疫苗組合的授權及核准，促進COVID-19全球疫苗研發及公平分配。 COVAX是WHO「獲取COVID- 19工具加速計畫（Access to COVID-19 Tools Accelerator, ACT Accelerator）」下的疫苗分配機制。ACT-Accelerator透過匯集各國政府、衛生機構、科學界、產業界、民間團體的力量，共同合作開發創新診斷方法、加速融資研發治療工具、制定公平分配與交付疫苗機制、確保衛生系統與社區網路連接等四大領域，以盡快結束大流行疫情。 COVAX作為COVID-19疫苗聯合採購機制，預計2021年底要提供20億劑疫苗，籌資181億美元；由GAVI與高收入國家簽訂投資契約，透過全球融資機制採購9.5億劑疫苗，同時搭配WHO制定的疫苗倫理分配架構，使COVAX能夠集中各國經濟體的購買力，保證候選疫苗的採購數量，鼓勵擁有專業知識的疫苗廠商盡速投入大規模的新疫苗生產，確保參與COVAX的國家及經濟體，皆能迅速、公平公正地取得大量有效的疫苗。 COVAX承諾將為全球92個中低收入經濟體提供參與COVAX的融資工具；超過80個高收入經濟體已提交參與COVAX的意向書，將從公共財政預算中編列全球疫苗研發的捐助資金，並與92個中低收入國家結成疫苗合作夥伴。透過COVAX機制產出的疫苗，將會按照參與國人口比例公平地分配給所有國家，並且優先提供疫苗給衛生醫療工作者、老年人及疾病弱勢群體；隨後再根據各國家需求、易受感染程度與COVID-19威脅情況，提供更多劑量的支援。
美國航空公司控告Google銷售不當的關鍵字廣告美國航空公司(American Airlines, 以下簡稱AA)，世界最大的航空公司，控告Google私自銷售包含AA的名稱或註冊商標之搜尋關鍵字 AA日前向德州北區地方法院提出訴訟，控告Google將關於AA的名稱或註冊商標的搜尋關鍵字，如「American Airlines」或「AA.com」，銷售給其它公司作為廣告用途。 AA表示，Google甚至將該等搜尋關鍵字銷售給AA的競爭者。換言之，當使用者於Google搜尋引擎查詢關於前述之AA名稱或註冊商標之關鍵字時，Google除了提供相關連結之外，也可能會在「贊助者連結」中提供AA競爭者的連結，而引導使用者前往其競爭者的網頁。 AA於聲明中指出：「我們希望能減輕此類行為所造成的損害」。截至目前為止，AA並未透露求償金額等細節。 Google則在其聲明中指出：「我們相信本公司的商標政策已經在商標所有人的權益以及消費者的選擇之間取得適當的平衡，並且我們的立場在相關案例的判決中已經被證實是合法的」。
落實資訊傳遞之流程透明與提昇效率，英國成立照護資訊標準化委員會資訊的保密機制和數據的標準化是當代的醫護過程中，相當關鍵重要的一部分，使得資訊得以安全地蒐集、記錄和交換，同時也是衛生照護系統在品質和服務管理上得以維繫的關鍵。過去英國負責處理醫療資訊交換標準的單位為「衛生和社會照護資訊標準委員會（Information Standards Board for Health and Social Care, ISB）」，負責就國家性的資料標準進行評核、統一資料標準格式，進而符合國際規範。為了因應國家治理在資訊標準、資料收集和資料提取上新的規劃，自今（2014）年4月1日起，ISB轉型為照護資訊標準化委員會（Standardisation Committee for Care Information, SCII）。 新的照護資訊標準化委員會－SCCI主要負責發展、批准並保障資訊標準、資料蒐集與資料提取。該委員會的成員組成廣泛地來自國家單位和相關衛生、照護服務組織。現階段的主要目標為標準化醫院和家庭醫生之間的醫療資訊交換，將醫療資訊標準提升至國家層級，透過該委員會的運作來監督、改善照護服務、照護系統和資訊的處理方式，進而達到流程公開和運作透明。以下為ISB轉型為SCCI之主要原因： 1、2012衛生和社會照護法（Health and Social Care Act 2012）之規定，該法§250賦予衛生部長和NHS England（英國國家健康服務）發布資訊標準的權力； 2、NHS成立新的國家資訊委員會（National Information Board, NIB），該委員會前身為資訊服務調查小組（Information Services Commissioning Group, ISCG），主要針對衛生和社會照護提供國家層級的資訊服務整合規劃，以確保資訊標準統一，使得不同IT系統間得以相互傳輸、驅動更多整合服務給人民。SCCI即隸屬於NIB，負責識別、調查和完整執行資訊標準、資料蒐集和提取。 3、衛生部於2012年發布衛生和照護系統的10 年資訊策略（ten year information strategy for the health and care system）。
歐盟執委會公布「數位金融包裹」法案為鼓勵金融產業之創新，同時使其遵循應有之責任，並讓歐盟金融消費者與商業機構享有更多之利益，歐盟執委會於2020年10月24日提出數位金融包裹法案（Digital Finance Package），並提出以下2項數位金融立法提案： 一、加密資產立法提案（Proposal for Markets in Crypto-assets） 為促進金融創新並同時保有金融穩定性與保護投資人，歐盟執委會提出加密資產管制框架立法提案，並將加密資產分為已受監管與未受監管兩類，前者將持續依據既有規範進行管理。而針對尚未管制之加密資產，該提案針對加密資產發行人與加密資產服務供應商建立嚴格限制，要求取得核准後始可提供服務。具體而言之，立法提案包含以下項目： （一）針對加密資產、加密資產發行人等金融商品名詞進行定義。並建立加密資產服務供應商與發行人營運上、組織架構與資產發行程序之透明度與揭露制度。 （二）針對向公開市場提供加密資產進行管制，例如，依據提案第4條，供應商應為法人，第5條則要求供應商應製作加密資產白皮書，並將其提供給主管機關後始可於公開市場提供相關服務。 （三）針對代幣資產發行人以及其加密資產之審核程序，依據提案第15條，代幣發行者必須為歐盟境內之法律實體。另外，該法要求加密資產發行人應誠實、公平且專業，並完成加密資產白皮書之出版與制定市場溝通規則。 （四）針對加密資產之收購，該法第4章亦設有相關規範，於第37條及38條規定收購之評估機制。 （五）針對加密資產服務供應商之授權與營運條件，該法第5章規定歐盟證券及市場管理局應建立加密資產服務供應商之登記制度。 （六）針對市場秩序維護之部分，該法於第6章規範相關預防市場濫用之禁止事項與要求，並於第7章賦予歐盟成員國各主管機關相關權力，例如第94條之監督與懲處權限。 二、歐盟數位營運韌性管制框架立法提案（Proposal for Digital Operational Resilience） 數位化總伴隨資安風險，歐盟執委會於包裹法案內亦提出歐盟數位營運韌性管制框架立法提案，以確保相關企業可應對所有與通訊技術有關之干擾與威脅，另外，銀行、證券交易所、票據交換所以及金融科技公司將需遵循嚴格之標準以預防並降低ICT資安事件所產生之衝擊，另外亦將針對金融機構雲端運算服務供應商進行監管。具體規範包含： （一）ICT風險管理要求：該立法提案參照相關國際標準，於第5至第14條制訂相關ICT風險管理要求，惟未要求應遵循具體國際標準。 （二）ICT相關事件報告：該提案於第15至20條規範相關報告義務，將整合歐盟金融機構之ICT相關事件報告與監測程序。 （三）數位運作韌性測試：該提案於第21至第24條要求ICT風險管理框架應定期進行測試，惟具體方法可依據組織之規模、風險側寫與商務模式進行調整。 （四）第三方單位風險：該提案於第25至39條規範組織應對ICT第三方供應商風險進行監測，例如，第25條要求金融機構委外執行業務仍應隨時遵循所有金融服務規範，另外，ICT風險管理框架之內容亦應包含第三方ICT風險之監督策略。