If there\u2019s a flaw in your IT security \u2014 and there probably is \u2014 you can\u2019t assume that someone in your organization will be the first to find it. But if you\u2019re lucky, instead of ending up with ransomware or a data breach, you might hear about it from a security researcher or even a smart customer who\u2019s spotted the problem and wants to warn you. Are you ready to listen?Many companies aren\u2019t, warns security consultant Troy Hunt. Hunt runs haveibeenpwned.com, a website that helps people discover if any of their accounts have been compromised by data breaches. Because of his role with the website, he routinely finds himself in a position to contact organizations about breaches and other security issues that he\u2019s found or that other people pass on to him.\u201cIt\u2019s often very difficult just to get in touch with a company in the first place \u2014 even the big ones. I\u2019m going through multiple data breaches and I just can\u2019t get the contacts,\u201d he told CIO.com. When he discovered some 40,000 patient reports from an Indian pathology lab \u2014 including sensitive information like HIV status \u2014 were publicly available, the obvious ways of contacting the lab didn\u2019t work. \u201cEmail was bouncing; even the WHOIS contact information for their domain was bouncing.\u201dAnother security researcher CIO.com spoke to had found a SQL injection bug on the website of a large grocery store. The site offered no contact details, so they used the online form for submitting issues. About 10 days later, they were notified that their \u2018request\u2019 had been forwarded to the store manager. Two days after that, they received a survey asking how they\u2019d rate the customer service they\u2019d received. At the time of writing, they still hadn\u2019t managed to confirm that the grocery store had received the warning.Slow responses aren\u2019t uncommon, notes Hunt. \u201cThere are a lot of even large organizations that don\u2019t have people in dedicated security roles and they don\u2019t have a process for how they\u2019re going to deal with this incident.\u201d When he notified consultantcy Cap Gemini that someone had found the database backups for their customer, recruitment firm Michael Page, in a publicly accessible folder share, \u201cit took over a week for them to figure out what had happened, prepare a response and notify people.\u201dOther researchers \u2014 even those working at large software companies \u2014 report that companies they try to notify about issues ignore reports, or respond with legal threats.A survey of the Forbes Global 2000 companies in 2015 showed the scale of the problem: Only 6 percent had a public method to report a security vulnerability. And yet, in November 2016, the U.S. Department of Defense posted its policy for how security researchers could submit vulnerabilities they\u2019d discovered in DoD websites, with clear guidelines for what researchers could investigate and when they\u2019d get a response. Isn\u2019t it time your company had its own \u2018see something, say something\u2019 policy?Process and point of contactThe first thing most security researchers wish organizations would do is tell them who to talk to. \u201cWhat I\u2019d like to see on every site is a contact; here\u2019s who to contact if you have a security question,\u201d says Hunt.But you also need to respond sensibly, and that means having the right procedures in place. \u201cI\u2019d like to get to where every company has a published statement acknowledging that they\u2019re going to have vulnerabilities and recognizing how they\u2019re going to handle them. You need to be clear on how you accept feedback, how you handle feedback and how you handle disclosure.\u201d\u201cIt is important to establish a process and an \u2018inbox\u2019 so that every request or report doesn\u2019t become a one-off request (or, worse, a fire drill),\u201d says Dwayne Melancon, vice president for products at security software company Tripwire. \u201cCreate an inbound email address or alias that is designed to receive these kinds of reports, and a known, documented process for dealing with the inbound reports.\u201dYou\u2019ll need to triage the reports that come in, you want to know if they\u2019re legitimate problems, how severe they are and what risk they expose you to. \u201cYou need to separate things that are clear and obvious security vulnerabilities \u2014 anything from SQL injection vulnerabilities to exposed files to improperly implemented HTTPS; they\u2019re in a different realm from a customer complaining that your password rules don\u2019t allow spaces,\u201d says Hunt.\u201cA highly exploitable issue that would have a critical business impact should jump to the front of the remediation queue and engage your top security analysts,\u201d Melancon advises. \u201cIn contrast, a question about your password policy should be routed to a customer-facing responder rather than a specialized security analyst.\u201dDon\u2019t ignore even small issues, warns HackerOne co-founder, Michiel Prins. \u201cSome of the biggest vulnerabilities are achieved by chaining together small and innocent vulnerabilities or missing best practices. My advice would be to investigate any claim of the existence of a vulnerability, even if it is around a missing best practice. If it is easy to implement, then why not do it? Defense in depth will pay off in the long term.\u201dThose password questions still need to get a good answer, with a sound security basis, but beware of doing that on social media, Hunt warns. \u201cMany people like to just fire off a tweet or leave comments on Facebook pages, but the last thing you want is a security discussion on public social media. First of all, if you\u2019ve got stupid password rules then you have an issue you need to deal with, and then the people controlling the social media account are often out of their depth. So many times, I see companies making bad statements under the corporate banner.\u201dYour social media staff will be turning to the company handbook to get an answer, so make sure it\u2019s in there. \u201cThen get the feedback offline and take them through your process.\u201dSecure by cultureFostering a culture of security starts with not getting defensive when you get a report of a problem with your systems. \u201cEven when it may be awkward in the beginning, show gratitude to the person who has the bravery to tell you about a security problem,\u201d says Prins. \u201cYou must realize that this person comes to you in good faith and that a security vulnerability in the wrong hands could do serious damage to your business and brand. Keep the person who reported the vulnerability to you informed throughout the process all the way from receipt to validation to resolution.\u201dThat\u2019s part of having the right attitude and culture in not just your security team, but also your engineering team, Prins says. \u201cYour engineering team is most likely responsible for fixing reported vulnerabilities. It is very likely they are also the group that introduced them in the first place. This is why the security team and engineering team need to have a healthy relationship. If engineering sees the security team as \u2018oh, those guys again,\u2019 you have a cultural and attitude problem to overcome first. If you have a dedicated product management team, you need to get them on board too.\u201dIn fact, dealing with vulnerability reports needs to be part of the way you design, implement and test your systems, which includes making sure everyone knows when a system is being launched or updated, he says. \u201cEspecially engineering teams, product teams, legal team and your communications team. When the first vulnerability from an external party comes in, it should not be a surprise for anyone.\u201d\u201cIn short, develop a culture where everyone involved truly believes security is important and fixing an externally discovered security vulnerability gets priority over most other things.\u201dThat culture will help the escalation process for serious vulnerabilities work well. \u201cYou need to have a smooth internal communication process, tight integration with the issue tracking software your engineering team uses, and maybe even appoint an individual who manages the internal coordination until a fix has been rolled out,\u201d Prins says. \u201cSome of the questions you need answered are: \u2018who owns doing the root cause analysis?\u2019, \u2018who owns the development and deployment of the fix?\u2019 and \u2018who owns investigating if the security issue has been exploited maliciously before?\u2019 For less impactful security issues, you can build upon your existing prioritization and escalation process for fixing bugs.\u201dIf you\u2019re looking for a formal method, surprisingly few people know that there are ISO standards for vulnerability disclosure (ISO 29147) and vulnerability handling processes (ISO 30111). The first is now free to download and gives you best practices for receiving vulnerability reports and responding to them. If you want to see how well equipped you are for that, work through the questions in this Vulnerability Coordination Maturity Model, which covers executive support, communication, analytics and incentives as well as IT and engineering.