<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1977396509252409&amp;ev=PageView&amp;noscript=1">
Contact a Specialist
Industry Solutions
Industry Solutions
Cloud Computing & Data Centers
Cloud Computing & Data Centers
Financial Services & Fintech
Financial Services & Fintech
Healthcare
Healthcare
Payment Card Processing
Payment Card Processing
US Government
US Government
Learning Center
Learning Center
Articles
Articles
Whitepapers
Whitepapers
Case Studies
Case Studies
Events & Live Webinars
Events & Live Webinars
On-Demand Webinars
On-Demand Webinars
Compliance Reliance
Compliance Reliance
About Us
About Us
Leadership Team
Leadership Team
Careers
Careers
Corporate Social Responsibility
Corporate Social Responsibility

Blog

The Schellman Advantage Blog

Stay up to date with the latest compliance news from the Schellman Advantage blog.

SCOTT ZELKO

Scott Zelko is a Principal at Schellman & Company, Inc. Scott leads the Northeast Practice and the ISO Certification service line. Scott has more than 25 years of experience in the information technology field including IT management, system implementations, attestation and other advisory services related to information security, general computer controls, systems and application development. In addition, Scott works with clients to develop unified compliance strategies to meet internal, regulatory and client requirements.

Blog Feature

SOC

By: SCOTT ZELKO
June 23rd, 2017

It may come as a bit of a surprise—maybe not—but there are actually two types of SOC reports. Upon examination, the service organization is responsible for specifying whether or not a “Type 1” or “Type 2” will be performed. It’s important to note the specific use of “Type” as a distinguisher--not “SOC 1” or “SOC 2,” as the different specified “types” are options for both the SOC 1 and SOC 2 reports. For those of you that are now thinking, “that’s confusing,” I agree 100% with you. In fact, “Type 2” and “SOC 2” are not at all the same thing, and the “type” of each SOC examination presents important differences for service organizations.

Blog Feature

ISO 27001 / 27002

By: SCOTT ZELKO
May 25th, 2017

When you think of a data breach, what comes to mind? It’s probably the image of a hacker stealing data from a large business or company that stores an abundance of customer data—like Target, for instance. Data breaches are expanding from companies and healthcare organizations and are also becoming a real concern for law firms.

Blog Feature

Cloud Computing

By: SCOTT ZELKO
March 31st, 2016

Surprisingly, business leaders—not IT departments—are the driving force behind six out of 10 migrations to the cloud. These leaders are often bothered by the nagging question, “Is the cloud secure?” This question is usually followed by a series of debates about just how secure the cloud is.

Blog Feature

Compliance and Certification

By: SCOTT ZELKO
November 19th, 2015

Despite years of preparation and billions of dollars in spending, today’s businesses still aren’t prepared for cyber-attacks. Just turn on the evening news and you’ll be greeted with the name of the latest company to suffer an attack.

Blog Feature

SOC | FAQs

By: SCOTT ZELKO
November 10th, 2014

There are two types of SOC 1 reports. The service organization is responsible for specifying whether or not a “Type 1” or “Type 2” will be performed.

Blog Feature

SAS 70 | Assurance / Service Audits

By: SCOTT ZELKO
October 29th, 2010

Imagine, for a moment, that you are sick and require a major operation. Among the many thoughts that would immediately cross your mind would be the need to find “the best” doctor available. What criteria would you use when selecting the best doctor? I bet that the following attributes would weigh heavily in your decision:

Blog Feature

Pharmaceutical / DEA | SAS 70 | SysTrust

By: SCOTT ZELKO
June 10th, 2010

On Monday, we posted an article announcing that the DEA had issued new regulations for “Electronic Prescriptions of Controlled Substances.” Since then we have further reviewed the ruling and also spoken with many clients and prospects that have contacted us on the subject. The following points provide additional context and background for any service provider (ASP, SaaS, etc) that provides an application for generating and fulfilling prescriptions of controlled substances. The primary goals of ruling are to 1) maintain a protected “closed system” for prescription fulfillment 2) reduce the risk prescription forgery and diversion and 3) promote the use of Electronic Health Records (EHR) building on the incentives and goals outlined in the Health Information Technology for Economic and Clinical Health (or HITECH) Act components within the American Recovery and Reinvestment Act of 2009 (a.k.a. the Recovery Act). Controlled substances make up approximately 10% of all prescriptions. That said, the classifications of controlled substances approved for medical use (schedules II through V) are carried by most major pharmacies. The control requirements, highlighted below, as well as the third-party audit requirements are focused on electronic prescription applications, which can be installed on a standalone basis or hosted by an Application Service Provider (ASP). A medical provider (i.e. doctor) or pharmacy is not required to undergo a third-party audit unless it develops the e-Prescriptions software itself. It is also worth noting that requirements for identity management and access control not only aim to protect access to data but to restrict who can generate, approve, and fulfill a prescription thus reducing the risk of unauthorized fulfillment of controlled substances (referred to as diversion). e-Prescription technologies have been available for some time and there are standards for the communication of prescription data between a medical provider and a pharmacy. For instance the SCRIPT standard (currently in version 10 release 6) specifies the data field requirements such that the data can be shared across different applications. The DEA clearly noted that it has “not been able to identify any organization that sets standards for or certifies pharmacy applications for security issues.”

Blog Feature

Pharmaceutical / DEA | WebTrust | SAS 70 | SysTrust

By: SCOTT ZELKO
June 8th, 2010

With the medical industry quickly moving towards electronic records and transactions, why wouldn’t pharmacies do the same?