Identification of Reportable Events Sample Clauses

Identification of Reportable Events. There are a number of ways that a Reportable Event may be identified. While it is impossible to list every possible situation or activity that may be or give rise to a Reportable Event, this document will strive to provide sufficient guidance to make Reportable Events readily identifiable. As a rule, over report. When in doubt, report. The EOHHS Security Office will help you identify a Reportable Event and will inform you if the event you reported was not, in fact, a Reportable Event. Reportable Events fall into two different groups: • Group 1: ongoing Security Incidents • Group 2: events that demonstrate environmental weaknesses that could lead to a Security Incident and need to be fixed. Group 1 is largely reactive. In a Security Incident, Information Resources have already been compromised either through confidential information being given to the wrong party thereby impacting the confidentiality of the data, being unavailable to the people who need them, or when the data is inaccurate such that people who need data are unable to get the right data. Therefore, in a Security Incident, damage has already been done to Information Resources or business processes. Addressing that damage involves stopping the spread and impact of the Security Incident (which could be a current or pending loss of data) and restoring the confidentiality, integrity, and availability of Information Resources as best as possible. Some examples of Security Incidents are as follows: • Loss of a mobile device(s) such as laptop, tablet or phone that is unencrypted o For encrypted devices, the System and Support Desk should be following their own lost device remediation plan which includes remote wiping of device • Widespread malware/virus infection • Confidential information disclosed, altered or destroyed • Unauthorized changes to system hardware and/or software • Unauthorized probing or scanning of Commonwealth systems or network • Denial of Service (DOS) or Distributed Denial of Service (DDOS) attacks
Sample 1Sample 2Sample 3
AutoNDA by SimpleDocs

Related to Identification of Reportable Events

  • Reporting of Reportable Events If Xxxxx determines (after a reasonable opportunity to conduct an appropriate review or investigation of the allegations) through any means that there is a Reportable Event, Xxxxx shall notify OIG, in writing, within 30 days after making the determination that the Reportable Event exists.

  • Definition of Reportable Event For purposes of this CIA, a “Reportable Event” means anything that involves:

  • Reportable Events No such Employee Benefit Plan which is an Employee Pension Benefit Plan has been completely or partially terminated or been the subject of a Reportable Event as to which notices would be required to be filed with the PBGC. No proceeding by the PBGC to terminate any such Employee Pension Benefit Plan has been instituted or threatened; and

  • Reportable Events under Section III J.1.c. For Reportable Events under Section III.J.1.c, the report to OIG shall include:

  • T1 IDENTIFICATION PROCEDURES During the restoration of service after a disaster, BellSouth may be forced to aggregate traffic for delivery to a CLEC. During this process, T1 traffic may be consolidated onto DS3s and may become unidentifiable to the Carrier. Because resources will be limited, BellSouth may be forced to "package" this traffic entirely differently then normally received by the CLECs. Therefore, a method for identifying the T1 traffic on the DS3s and providing the information to the Carriers is required.

  • Reportable Events Involving the Xxxxx Law Notwithstanding the reporting requirements outlined above, any Reportable Event that involves solely a probable violation of section 1877 of the Social Security Act, 42 U.S.C. §1395nn (the Xxxxx Law) should be submitted by Practitioner to CMS through the self-referral disclosure protocol (SRDP), with a copy to the OIG. If Practitioner identifies a probable violation of the Xxxxx Law and repays the applicable Overpayment directly to the CMS contractor, then Practitioner is not required by this Section III.G to submit the Reportable Event to CMS through the SRDP.

  • CERTIFICATION REGARDING DEBARMENT, SUSPENSION, INELIGIBILITY AND VOLUNTARY EXCLUSION This provision is applicable to all Federal-aid construction contracts, design-build contracts, subcontracts, lower-tier subcontracts, purchase orders, lease agreements, consultant contracts or any other covered transaction requiring FHWA approval or that is estimated to cost $25,000 or more – as defined in 2 CFR Parts 180 and 1200.

  • ADDITIONAL REPORTING REQUIREMENTS Contractor agrees to submit written quarterly reports to H-GAC detailing all transactions during the previous three (3) month period. Reports must include, but are not limited, to the following information:

  • Certification Regarding Responsibility Matters This provision applies to solicitations where the contract value is expected to exceed the simplified acquisition threshold.

  • CERTIFICATION REGARDING DEBARMENT AND SUSPENSION The undersigned (authorized official signing for the contracting organization) certifies to the best of his or her knowledge and belief, that the contractor, defined as the primary participant in accordance with 45 CFR Part 76, and its principals:

Time is Money Join Law Insider Premium to draft better contracts faster.