This is a marketing message we put out to our customers and prospects. It seems like it is the time of the year for the annual pen test. Did you know Jacadis did them? If you need to have a pen test as part of your annual audit process, for compliance purposes or just because it is a best practice activity and it has been awhile, we'd love to know how we can help.
Do you know your attack surface? Do cybercriminals know?
Unethical hackers are motivated, skilled, and equipped to steal from your company -- regardless of staff, budget, or industry. JACADIS can help your organization understand your attack surface, as well as teach you how to protect it.
Prevention is not enough
Firewalls, IPS, antivirus, and web application firewalls are no match for organized, highly sophisticated criminals. If your company is in their cross-hairs, they will break-in. When they do, will you know?
... levels the playing field by safely emulating the tactics of cybercriminals -- not just to penetrate your network, but also to identify blind spots in your detection and response mechanisms. In addition to finding and exploiting weaknesses, we run a series of "what-if" scenarios that assume the break-in is a foregone conclusion.
JACADIS will...
Evaluate your corporate awareness regarding social engineering attacks;
Optimize your incident response processes to account for sophisticated attackers and insider abuse;
Find your security gaps and blind spots, then provide guidance on tuning your IPS/SIEM;
Educate your staff regarding threat models, illustrating traffic and attack paths to and from the Internet, mission critical systems, and end users;
Report details on who clicked what, and what was "visible" from their system;
Generate a detailed report for technical personnel and executive management;
Provide a road map of prioritized risk-based "next actions" to remediate the most critical vulnerabilities first.
If you need a quality Penetration Test we'd love to have the opportunity to help. Contact our sales team at sales@jacadis.com or http://www.jacadis.com/About/ContactUs/tabid/83/Default.aspx.
With compliance efforts the question is "Which way do we go?! And most times the signs are just this clear! Image by bob august via Flickr.
Two weeks ago, a financial services client of ours asked me “how compliant is compliant enough?”
They’ve been a good client for over 15 years. They are good people who care about their customers. They follow a disciplined approach to IT operations which provides a great foundation for their information security program.
At first, I was blown away by the comment.
How could they even consider such a question?
But the more I reflect on their comments and their situation, a new question has come to mind.
Who could blame them?
With the HITECH changes to HIPAA they unequivocally fall into the frame of HIPAA compliance. They by law are obligated to do more than they do now to secure their customer data.
They are doing a lot and doing it well, though they know they are not perfect.
Their wireless network is 100% impervious to outside invaders; they decided the risks of deploying outweighed the business risks of implementing wireless. Over 10 years of having 3rd party security assessments their technical team and technical infrastructure have consisently passed muster (ours wasn't the only firm evaluating them so the consistent findings were from multiple firms using multiple techniques and tests). A recent HIPAA Security Rule Gap Assessment Workshop that we facilitated found that from a HIPAA standpoint they were doing the vast majority of the controls in the security rule.
They are "doing" security but they don't document at a policy or procedure level what they do. Their staff is aware of security issues, but less so about privacy issues, particularly pertaining to information handling practices within the organization. In those 10 years of tests a couple of the assessors have been able to penetrate their physical security through social engineering. Security and privacy is an IT focused effort.
We believe that they are well secured against external attacks but are vulnerable to inside threats and accidents or to interuptions in their business process.
Fixing those business related issues all boils down to revenue versus expense, and they aren’t sure they can invest the time and treasure to attain perfect compliance.
And so the honest question is asked, “How compliant is compliant enough?”
Although they only ask one question, I suspect they had a few other questions they didn’t verbalize:
If we don’t do anything will we really get in trouble?
Will the government really enforce the law? They haven’t really yet have they?
If we do all this extra work won’t the work cost more than the likely fines we’ll pay if we don’t do the work?
Are our competitors doing it? Do our customers care?
In the time they’ve been wrestling with these questions they could have substantially closed the larger gaps in their program. But they are frozen by the uncertainty.
They are not the only client that is frozen by regulatory uncertainty.
Truly, with the way our government regulates information security and privacy I don’t have good answers for those questions.
Regulatory uncertainty is in and of itself a threat to privacy and security, and regulatory non-compliance is a risk that needs to be managed.
In the face of uncertain and confusing regulatory options most businesses in our experience choose to do nothing.
Regulatory uncertainty manifests itself in a number of ways:
Uncertainty due to a lack of knowledge about the potential regulations on the part of businesses
Uncertainty about just what various regulatory agencies are doing
Uncertainty about just what various regulatory agencies are going to do –
Uncertainty due to the myriad of fine line distinctions and confusion in the regulatory body
Uncertainty because of the confusion about which regulations apply to a particular firm or type of firm
All of these types of uncertainty are born out of poor communication, difficult language, sudden course corrections as rules are morphed in the political process even after they’ve been published,
The Red Flags Rule requires many businesses and organizations to implement a written Identity Theft Prevention Program designed to detect the warning signs — or "red flags" — of identity theft in their day-to-day operations. It was first passed in 2003. The FTC moved the enforcement date three times. Depending on whose view you take that was because they bent to lobbying from interest groups representing doctors, lawyers and higher education institutions OR they were listening to industry and adjusting the rules to meet the feedback they were getting. From either perspective the enforcement date continued to slip.
In December 2010, the law was amended with the Red Flag Program Clarification Act of 2010 to focus the law on its original intent.
(NOTE: Did you catch that last line: “Bookmark this site and check it often for revisions that reflect changes in the law.” Often? How often? Changes? What changes? How do I plan for those changes? Are you kidding me?)
HIPAA or the Health Insurance Portability and Accountability Act (HIPAA) of 1996. HIPAA has five titles covering an array of topics. Title II ironically known as Title II of HIPAA, ironically known as Administrative Simplification, primarily requires the establishment of national standards for electronic health care transactions . Administration Simplication also address the security and privacy of health data. The standards are meant to improve the efficiency and effectiveness of the nation's health care system by encouraging the widespread use of electronic data interchange in the U.S. health care system.
Based in part on the poor adoption rates of and loopholes in HIPAA, Congress passed HITECH.
HITECH the street version of the mouthful formal name Health Information Technology for Economic and Clinical Health (HITECH) Act, was enacted as part of the American Recovery and Reinvestment Act of 2009. It was signed into law in February, 2009. It primarily promotes the adoption and meaningful use of health information technologies such as Electronic Health Records (EHR). Within HITECH, Subtitle D addresses privacy and security concerns associated with the electronic transmission of health information primarily through a number of provisions that strengthen enforcement or clarify the original HIPAA rules.
Yet, uncertainty surrounding HIPAA is epic:
Poor enforcement impacted HIPAA adoption rates so HITECH was passed to provide stronger enforcement. We have seen an increase in enforcement action as well as an increase in awareness for breach events through HITECH’s breach reporting requirements but it has not reached a tipping point that catches decisions makers’ attention in a way that motivates them to act.
Rules that were to be out by now are not published. Rules have been published and pulled. Published dates have been moved around the calendar. We know that subcontractors are covered under the Security Rule but the rules have not been published. We know that there are mandatory audits required under HITECH but we don’t know exactly what that means.
Rules sometimes just don’t make sense. For instance, the Security Rule is focused on ePHI or electronic Protected Health Information. Think technical infrastructure. The Privacy Rule is focused on PHI in any form. Think use, handling and behavior. A fax is not considered ePHI though in most environments today many faxes come in and outbound through unified messaging. What is compliant action in regard to action
The government has produced an alphabet soup of laws, rules and regulations FERPA, Sarbanes-Oxley or SARBOX or SOX, GLBA, all with similar stories. And there are legislative efforts to move forward with a new batch of privacy and security laws covering related topics such as national cyber security, privacy, security standards and breach notification. With the continual onslaught of breaches the political will is building to enact and execute a national law focused on information security and privacy.
So into this clear as mud uncertainty we now have political activity driven by the epidemic of breaches that is leading us to a more laws, rules and regulations, and as I would suspect more uncertainty and with it more frozen clients caught between their fear to act and their fear not to act. And doing nothing puts them and their data at risk.
So we think the question isn’t “how compliant is compliant enough” but rather “how can we position our firm to lower compliance risk in light of this uncertainty while focusing on doing the right things to protect our customer and other critical data”
We suggest the following:
Stay focused on the basics. We recommend you start by defining a standard language for internal information security discussions. We at Jacadis like ISO 27001. The ISO 27000 series is an internationally recognized family of standards focused on turning information security, privacy and compliance into a management function. Adoption of ISO 27001 provides a framework and language from which to build top down, management to technical information security, privacy and compliance function within an organization. The framework will provide a standard way of managing security and once adopted assist in building resilience to changes in compliance standards while keeping you focused on protecting the most important information assets in your stewardship. For additional reading on ISO 27001 I suggest an IT toolbox article by Jacadis’ Jerod Brennan.
If you don’t have someone tracking the laws that affect your company, the cost to become compliant is going to hit you like a ton of bricks. Stay on top of it. Ounce of prevention is worth a pound of compliance, er… cure.
And while I don’t suggest you get get caught up with the what ifs and could bes as the legislative process moves forward. If you are an information intensive organization it is a good idea to have an executive level team member monitor the legislative process. You may find there is a moment that calls for your attention to get involved politically if legislation gets restrictive in a way that could impact your business.
We had a unique call come in yesterday, one I wish we had more of, but we don't.
A small business owner with a brokerage of sorts wanted to develop a website that would allow the producers and the buyers to post information, in some cases highly personal information, review non-confidential subsets of the data about the other and keep the whole thing secured from the outside.
She asked if we could help and provide "small business pricing quotes."
In fact, I don't think many security firms get those calls.
Most of our calls are after the fact either after the app or system has been developed or just after it has been breached.
She called us asking questions because she didn't have any answers. I think that approach serves us well in many endeavors.
We can help her. We offered to help her develop a list of functions and safeguards she needed in her application, help her manage the procurement process and then to test the application for security before she accepted it from her developer.
In 10 years of business that was a first.
Most web applications, particularly web applications are built with out much thought to information security, customer privacy or regulations covering the information.
Truthfully no application is 100% secure. But an application that has been designed and developed with careful consideration for its information security, user privacy and regulatory requirements stands a great defensive chance once it has been launched. Testing that application before launch further raises the defensive posture. Regular testing and a proper operational routine after it has been released to production even further raises that posture.
Again, our experience has been that most businesses, particularly small business, design and develop applications, release them to production and then through some event realize that security is a concern. There is a breach or a break-in. The site is knocked off line by a denial of service attack and revenue streams are interrupted. The invoice from the payment card processor is higher than they want to pay and they find it is because of non-compliance with PCI. And so on.
This occurs because two things don’t happen up front:
Security just isn’t talked about as part of the deisgn process. It must be!
An assumption is made that developer and hosting providers on the project will handle security. In most cases they won’t unless you demand it of them and back the demand up with contracts and tests.
Here is a list of non-technical questions you need to consider as part of your design conversation. Getting technical on some of these issues may require a member of your IT staff or an outside consultant. But any small business owner should be able to answer these questions if they are trying to build a business using technology:
What is the sensitivity of the data on our planned site? Is it regulated data?
Who regulates the information or audience that uses our site? What are your obligations to protect it? What are your obligations to maintain user privacy? Does your privacy policy match that obligation? Will the site be developed with the guidance of a privacy policy?
How long can the site be offline before it negatively impacts our business? When will customers usually visit the site to transact business? If we are off line an hour of peak traffic time how much revenue will we lose? Profit?
What do our customer’s expect from us in regard to protecting their privacy?
Will you have user forums or accounts on the site? How will you verify those signed up are really customers? Or really people?! Does that matter? Will you allow any and all comments in your forums? Do you need to edit them or block them?
How does the developer ensure the web application is secure? The database?
How does the hosting provider help secure your application? How will you know they are doing their job?
You then need to make sure that your development partner builds the site to meet the requirements these questions should raise to the surface.
That site must be deployed in a technical environment that is at minimum protected by:
Proper and verified operating system and application hardening procedures
Separation of the development (where you’ll continue to create and innovate as well as test) and production
We then recommend you test the site against your requirements to make sure they were met (best to do that before that last check goes to the developer!). We also suggest you conduct a vulnerability scan against the site to make sure that it wasn’t developed with technical weaknesses a hacker could use to create havoc for you.
And then finally we recommend that you, as a matter of routine, continue running those tests to make sure the sight maintains the secure posture you paid for in the first place.
Jacadis helps businesses prepare and respond to security questionnaires and audit requests from their usually larger customers. We also are the audit and assessment team for some firms who choose to use external resources to review their key vendors' security.
Frankly, as breaches Epsilon isn't a big of deal. No protected information, just names and email addresses were taken. And more sophisticated attacks have come and gone in the press largely unnoticed.
Epsilon has received more attention than the more impactful breaches in part because it touched so many people. Non techies are talking about it. We believe that buzz is going to find its way into the executive suites and audit teams of big companies and boost the rigor and frequency with which larger firms test, prod, and assess their supply partners.
Experts suggest that companies that outsource technology services take some of the following steps:
Make sure the vendor has a recognized certification for information security, such as ISO 27001 or SAS 70 Type 2, granted by an accredited auditing organization such as the International Standards Organization;
Sign agreements that oblige vendors to undergo regular audits by third parties, at least annually. Auditors should test software (especially software that can be accessed via the Internet) and hardware as well as people, to ensure that vendors’ employees themselves don’t fall prey to scams;
Make sure vendors assume liability for breaches that affect customers and end users; and
Make contingency plans with the vendor so that neither is caught by surprise in the event of a security breach.
Management consultants and corporate governance experts are providing similar advice to their Fortune 2000 and similarly sized customers. These recommendations have been around for several years, however, the buzz from Epsilon has the potential to fuel the recommendations to reality.
This will impact you if you answer yes to any of the questions below:
Your business is part of the supply or services chain for larger regulated firms. We see most of the third party verification activity from firms that have regulatory obligations to HIPAA; PCI, GLBA or other financial privacy rules, or Sarbanes-Oxley. We have seen these type of firms apply the highest security and privacy standards to their vendors even if their vendors don’t process confidential or protected information. Do you provide services to these types of firms?
Your business provides a service that includes considerably volatile information. If, for instance, you process non-protected personal information but it is somehow seen as critical to your client’s business or it’s relationship with its customers this might apply. Or, if, for another instance, you process company confidential information such as trade secret related information. Do you provide services to these types of firms?
Firms in the supply chain stack. You may not be doing business with a regulated firm, but you may be providing services to firms that provide goods or services to firms that provide services to regulated businesses. You know what they say about it rolling downhill. Are you at the bottom of a supply chain?
Take action
If you answered yes to any of those questions we suggest the following:
1. Look at your customer agreements with firms in the categories above.
Do any of those agreements place obligations on your company to protect your client’s information in a certain way?
Do they have the right to audit?
Have you told your IT team about these obligations?
Are you prepared to meet these obligations?
2. Sit down with your technical leadership and discuss:
Are we secure? Vulnerable? Do we follow a best practices approach to information security? Which one?
Do we routinely check through tests, assessments, and/or audits our answers to the questions above?
If we got an auditing letter from an existing customer would we be ready for the audit in a week? a month? 3 months?
When the auditor arrives do we have documentation that defines our security programs values (policies), details the routines we follow to meet those values (processes), shows that those routines are being followed (logs, action reports, scorecards, etc.) and that our staff is aware of their obligations (awareness training)?
If we committed during the sales process with a new customer to do certain things to secure their data did IT and the others in the company responsible for delivering on that obligation have a hand in the answer? Are we overcommitting?
Are we managing security well enough that we can create a competitive advantage over other firms in our class? Can we use that advantage to build new business?
If your business provides business to regulated businesses upstream in your market we recommend you keep asking these questions until you feel comfortable with the answers.
Jacadis Presents - The Impact of PCI 2.0 - 136 changes you need to know
Jacadis has helped a large number of clients navigate the PCI waters. We upgraded our ability to provide services in that space when we added Jerod Brennen, formerly with large retailer Ambercrombie & Fitch, to our team. If payment cards are important to your business I invite you to this free webinar to learn what Jerod has to say about the changes between PCI-DSS 1.2.1 and PCI-DSS 2.0.
The PCI Security Standards Council introduced 136 changes between version 1.2.1 and 2.0 of the PCI Data Security Standard.
This presentation will help you understand what changes your organization needs to make in order to maintain compliance.
The PCI Standards Council released a summary of the changes to their Data Security Standard. The new version, known as PCI DSS 2.0, adjusts the standard from the 1.0 version, begins a move toward a more risk based approach and adds some requirements such as knowing where your card data resides and logging web applications.
With the announcement today we have not had a chance to look at it. I'll provide a review next week. Just know that headed into the Fall there may be changes to the way your company uses or protects cardholder data.
If you have specific questions please post to comments and I'll include the answers in the review I provide next week.
Information security compliance continues to motivate conversations with new and prospective customers. Customers more and more realize they can be secure without being compliant. Many times that lesson comes on the tail end of a failed audit, new regulation or new customer request. They then call us for help because showing compliance reduces a cost, maintains a client relationship or opens a new opportunity.
Typically, regardless of the alphabet soup (HIPAA & HITECH, SARBOX, COPPA, PCI DSS, FERPA, etc.) that the client is struggling with the reasons for the compliance failure boils down to a consistent list of Administrative and Technical failures.
The administrative failures impact compliance in manner more pronounced than the technical failures. Administrative failures generally mean a lack of prioritization within the security program. A technical security staff can only do so much without management and leadership providing direction.
The typical administrative failures include:
Information Security Program Management and Governance:
Security programs (read operations) are not formally managed as are other business processes within an organization so there is a lack of centralized, coordinated effort.
Security programs are paper only with a documented organization, steering committee charter, policy and procedure. But that program fails under the inspection of an auditor who wants to see committee minutes and proof that policies and procedures are in place.
Data Protection:
Information is not classified or controlled based on its value or the risks to its confidentiality, integrity and availability. Without that priority security investments are spread evenly over the entire organization rather than being focused on the most critical assets. And then the company softball team schedule is protected at the same level as the secret sauce, the general ledge, the customer list and the historical credit card transaction database (do you even need that last one?!). Which means you are either spending too much or not enough.
The company operates by handling critical, often times protected, information without any or at least without adequate handling procedures. Information is exposed through the normal course of the day because your employees "just doing their jobs" are doing them in a way that exposes you and your customers.
Security Awareness:
People are a critical link in the security chain and in the compliance chain. If we don't tell our teams what is important to protect, why and how, they will work in a non-compliant fashion and expose themselves, you and your customers.
Technical issues are generally tied to the administrative, programmatic issues above. If the company understood the risk of operating in a non-compliant fashion they would make the technical investments necessary. But because the administrative / management side of the equation is not in the know the technical team can't make the case for required controls. Typically we see the following controls shortcomings in a failed compliance conversation:
Technical Architecture or How Your Computers and Network are Set up to Work Together:
Architecture does not account for critical data. Architecture does not account for specific compliance requirements. Architecture is old and outdated. Baseline protections, or those considered absolutely necessary to protect a company such as strong passwords, anti virus, firewalls, and the like are missing or out of date or poorly managed.
Visibility:
Neither event logging and aggregation or intrusion detection is in place meaning the organization doesn't know what is normal or when something abnormal is happening. Most compliance constructs include some level of expectation for basic visibility for network activity.
Similarly, vulnerability management tools are not in place so technical staff doesn't have a tool-set to help them keep track of weaknesses that may creep into the network or the systems on it.
Data Protection:
Going hand in hand with architectural weaknesses many times we'll find companies made investments in technologies that include security features but didn't turn them on. With little to no investment both security and compliance can be improved IF these features are turned on. This includes basic logging through syslogs on systems, more complex logging in applications, firewalls built into operating systems that aren't turned on and use of strong passwords.
Is security and compliance on your management radar? On your customers'?
Secure Value by identifying your information inventory and then understanding what containers --- filing cabinets, computer systems, storage systems, data bases -- hold them. You then work to protect each container based on the value inside.
We suggest that you carefully and thoroughly identify your vital business information as a starting point to preserve its confidentiality, integrity and availability. It also a necessary exerscise to determine what compliance requirements must be met.
Different types of businesses operate with different concepts of vital information. A health care service provider, a retail store and a software publisher all have to protect their vital information, but each company’s inventory of vital information will be different. So being focused on compliance with a single standard may result in your losing focus on protecting all of your vitals
(NOTE: This is a negative with PCI. Many companies equate PCI compliance with overall information security. But PCI only focuses on one information type. Taking your cue from a compliance standard may leave you exposed!)
The techniques used to safeguard your vital information will be similar regardless of type though how that information is collected, processed and stored might change specific choices.
Regardless you can’t protect what you don’t identify.
What information types are vital to your business?
Compensation data
Computer processes
Computer programs and codes
Customer lists
Customer preferences
Financial information
Labor relations strategies
Marketing strategies
New materials research
Pending projects and proposals
Proprietary production processes
Research and development strategies
Scientific data
Scientific formulae
Scientific prototypes
Technological data
Technological prototypes
Others?
The function of a security steering committee includes inventorying the information assets of the company in order to understand the full scope of what needs to be protected.
A security steering committee, a team focused on your security, privacy and compliance challenges, is as critical to tackling continuous improvement as it is to compliance.
Information Security is not just about information technology. Discussions about information security in your company need to include more than just your technology team. A committee that blends information technology with your information and business process owners is necessary to have the discussions you need to have to secure value.
Many regulatory standards and best practice guidelines have some version of a security team. And rightly so because it is a best practice to have information security discussions at a business, not technical, level so you know you are making the right choices for your business.
Committee Formation
The typical committee should include information and business process owners as well as information technology. In larger organizations we'll see committees made up of 6 to 10 people. In some smaller organizations, particularly fast growing emerging businesses, a 2 person committee works. Regardless of size, the following functions should be represented:
Executive
Human Resources
Client facing representative (Sales or customer service or service delivery team manager)
Legal
Finance & Accounting
Compliance (if you have separated the compliance function by assigning it to multiple people the committee is critical to maintain communication between the compliance officers)
Committee Function
The committee should regularly meet and discuss how information security impacts your business. Some items for discussion:
What are our obligations to protect information? Government? Supplier? Customer? Partner?
How do we value security and privacy and the information within the business?
Do we collect, process, store and share customer (and employee) information in a way that meets legal, ethical and policy obligations? Are information handling practices exposing information?
How well is our security program in meeting those obligations?
In working with my clients I've also addressed some specific issues such as:
A new prospect expects your company to provide a SAS70. Is the new customer worth the investment in added scrutiny? Do you walk from the deal? Do you negotiate? Do you invest?
A new market includes customers in a highly regulated state that will force new compliance requirements on your firm. Is the growth worth the required compliance investment? Do you refocus your interest on another market with a lower entry cost? Grow into the new state and ignore the law? Grow and invest to become compliant with the new law? Across the company or just those local to the new territory?
A typical committee will have a flurry of activity up front setting policy, determing measures, identifying information assets and assessing information security and privacy. A well managed committee can meet on a monthly to quarterly basis if things are well organized and focused on a consistent agenda of progress, measurement and correction.
Are you finding larger customers are increasingly asking questions about your information security and privacy practices?
Yesterday, we met with a client that provides services to a horizontal business portfolio including firms serving a diverse set of vertical markets. Many of these markets have regulated information privacy and security practices at the local, state and/ or federal level as well as through contractual obligations with suppliers and customers.
As a service provider our client is being asked on a customer to customer basis to show compliance with this myriad of regulations. With each customer request comes a different state law, a different federal regulation, and a new pile of letters in the alphabet soup.
As my client exclaimed, "The volume of these questions just keeps growing. And most of the time they are asking questions that don't even pertain to what we do for their company."
The volume of requests is climbing because larger, regulated businesses through simple prioritization, have realized that now that they have their own houses in order (sorta, somewhat) their greatest risks lie in the information handling of their information by vendors, partners and other third parties.
They are asking questions that don’t pertain to my client because the audit and security teams know how to ask questions to secure the information in their business. Given the volume of vendors, partners and other third parties they must address they don’t have time to move far off the path they are used to or to get creative.
So you get some strange requests that require a valuable company staff member to answer questions to prove something that really shouldn’t need proving. Some other examples from my client base:
A design firm dealing in product design is asked to show how they protect protected health information under HIPAA from their insurance company client even though they don’t maintain health records. It is what their customer expects to build trust.
A collections network is asked to show how they maintain the privacy of collections records under Graham Leech Bliley even though what they do has been vetted by an attorney not to be covered by GLBA. It is what their customer expects to build trust.
A Software as a Service application publisher is required to prove they manage their network to conform to the Payment Card Industry’s Data Security Standard even though – you’ve guessed it by now – they don’t take credit card data. It is what their customer expects to build trust.
Customers expect their vendors to treat their information as if it your own. Call it stewardship. Prospective customers are going to probe for your ability to be a good steward as they explore your operations through the RFP process or through Q&A during the sales process. Customers are then going to probe for continuity of that good steward's stance as auditors ask for information that shows you are doing things their way.
Failing the questions during the prospects presales process will cost you a sale or make that sales win that much harder to earn.
Failing during the audit stage will cost you a customer and depending on how you fail (as in the case of a breach driven post incident audit) may cost more.
How do you represent yourself as a good steward when multiple customers are asking for different things?
Given the increasing volume of requests covering multiple compliance constructs my company, Jacadis, recommends creating an internal information security, privacy and business continuity organization (committee, team or whatever you might call it) using the ISO 27000: Information Security Management Model. The model, an internationally recognized standard in the information security field, provides a framework from which to evaluate and/or organize an Information Security Program.
The team then focuses on the most likely risks facing the company balancing your own information security, privacy and business continuity concerns as well as those of customers and prospective customers.
The committee, properly assembled, organized and managed, can then anticipate customer needs, respond to them more cost effectively and more efficiently and in most cases we’ve seen create a competitive advantage for the company. It is likely your competitors are dealing with the same issues. The ISO based committee structure gives you a tool to do it better, cheaper, faster.
How do you handle customer requests to “prove” your information security, privacy and business continuity plans? Are they just asking? Or would wrong answers .. not having a program … tarnish the relationship?
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=fed1329a-9b91-4736-902d-ba7596179a22)
