let's talk about risk management today a couple weeks ago we had a session on grc governance risk and compliance just to recap that is a combination of four different modules risk management policy and compliance management audit management and vendor risk management all four of the plugins are scoped they can be used individually by themselves but they do work best when they're all used together we're going to talk about risk management today risk management is basically a set of processes where we do four different things we try to identify the risks to the enterprise that come about because obviously we're using i.t we're using people and anytime that happens we have internal vulnerabilities that are subject to internal and external threats to just basic down into common language think about it this way people can cause problems it can cause problems if it's not managed correctly outside forces can cause problems if we don't do everything we can to keep it from happening risk is the process of identifying what needs to be done to prevent things from happening as we identify those risks it comes to basically evaluating the impact of what that risk means to the enterprise impact can be something as subjective as it has a high impact or a low impact or it can be something as objective as to the dollar or penny this is what it's going to take to replace a server or to rebuild our data center should something happen to it this is what it's going to take financially to respond to a lawsuit or to pay a fine these are all risks that are brought about because hey people using i.t using facilities we're vulnerable to certain things once we evaluate the impact we have to prioritize the order of addressing these risks and that is where we talk about likelihood yes things may have high impact but how likely is it to be realized is it sometime in the next five years we could see this happen or is it sometime the next two months that's where we address the priority of addressing a risk if it's very high impact but not very likely we may want to put off addressing that risk until a little later and then fourth is the actual addressing how are we going to address the risk do we just accept the fact that it could happen and deal with it when it does or do we start looking at the controls that are in place do we start looking at buying insurance all of us deal with risk on a daily basis we get into our vehicles maybe not so much now but we get into our cars and we go out on the roads we're dealing with machinery and individuals and that means that we're vulnerable we get into our cars and we address those vulnerabilities by using our turn signals and buckling our seat belts if you ride a motorcycle then you hopefully address those risks by wearing a helmet and potentially other safety gear we always address risk we just don't realize it once we start addressing risk and we look at those in service now servicenow gives us two different styles of evaluating risk these are out of the box functionality that is basically built in and the ability to flip between the two is controlled with a system property very very simple to set the two perspectives that servicenow provides are qualitative versus quantitative analysis qualitative analysis is very very subjective we're asking for a simple perspective of an individual what do you think the impact is servicenow gives a five-point scale and it could be well i think the impact is very low or it could be i think the impact is very high we also ask what they think the likelihood and again there's a five point scale and we think of is it very likely to happen in say the next six months or is it very unlikely to happen in the next six months and maybe it's likely only in the next five years quantitative goes to an objective analysis and it asks for two different things it asks for specific financial ranges of impact and the statistical likelihood on a percentile basis that something may happen usually this is not available to risk management really at the outset while it's something that the data can support if you start digging into it they usually aren't ready to go that route quantitative analysis is usually a later wave 2 wave 3 or wave 4 move down the road on the risk roadmap because they just don't have the underlying foundational data to provide that information in most areas of the business in dealing with our clients the one area of business that they can usually get down to the penny is equipment and facilities one of my former clients was a bank and when i talk about risk management i talk about the ability to replace a specific facility i lived in hawaii for two years and visited the big island where the volcano is and was able to basically utilize the concept of complete and utter destruction of a facility by talking about a bank bank america is of course a national bank there are branches over in hawaii there is a branch on the big island and of course there are branches all over the united states when you look at the risk analysis for specific facilities the risk analysis for a facility say in columbus ohio where i live is much different from the risk analysis that has to be done based on a branch being on the big island of hawaii they face an additional risk if that volcano erupts then the risk of total utter destruction of that branch is very high it's not very likely but you have to take that into account and because cost has been expensed to build a facility we can get down to the penny to what it would probably take to replace it same thing for a data center we know how much it costs to install the data center from the plenum below with all of its cat5 and etc to the plenum above with its halon 2000 or newer fire suppression systems we know what it takes to build it down to the penny we know what the cost of every single server so when it comes to a data center or a facility we can do a specific financial range of impact we can also look at the statistical analysis of things happening across the industry or simply across the nation and say data centers while extremely high financial impact if we have to replace one don't really have a lot of fires that happen they could but we addressed those so that's why companies kind of stay away from quantitative analysis they just don't have the underlying data except in a few areas when it comes to responding to risk once we've done the analysis and we say well the risk of this event happening is x it has this much impact and this much likelihood we have to decide what we're going to do about it that brings us to four different options we can try to avoid the risk we can simply mitigate the risk we can transfer it or we can simply accept it if we're going to avoid the risk it means getting rid of one of the two sides a risk realization is the confluence of a vulnerability being addressed by a threat the idea of a hacker the external threat poking around the network trying to get in and find a vulnerability that they can exploit that's where we try to remove vulnerabilities we're constantly patching operating systems removing vulnerabilities that threats could exploit we're constantly say if you're running a windows operating system we're constantly upgrading to the next version to get rid of the vulnerabilities that older versions have we want to avoid those risks by removing the vulnerabilities very rarely can we actually avoid the threat it's very difficult to avoid external threats especially but it's much easier to avoid the vulnerability by simply patching that operating system or moving to a much later much newer version of say a router or switch or a hub or a server if we're going to mitigate a risk we're simply talking about putting processes or controls in place that reduce the negative impact or reduce the probability they usually don't do both but they usually address one or two business functions that address either or when it talks about negative impact how much impact can something have we talk about a fire fire in the data center fires could still happen but we are going to mitigate the impact of the fire with a fire suppression system we may have a little bit of impact by a fire but the fire suppression system is going to drastically reduce the impact from critical impact it's very high impact to minor impact or a lower level of impact we put access controls in place to address the likelihood of something happening say on a server or an application we constantly assess those access controls to make sure that external threats can't get in and exploit existing vulnerabilities so the addition of access controls can help mitigate the likelihood transferring is probably the one that we are all most comfortable with and use without even thinking about it we buy car insurance we buy life insurance we buy rv and boat and motorcycle insurance we buy health insurance that's all the transfer of risk to a third party if something happens and a fire damage is part of our home we're transferring part of the liability or part of the cost to another person we're transferring it to our insurance company the same thing can happen with it when it comes to the transference of risk for say a data center fire or the facility loss something like that where we buy insurance to mitigate our responsibility we're transferring part of that over to the insurance company we can also accept the risk some risks are of such low probability and low impact it may not be cost effective to put anything in place to address that it may not be cost effective to transfer that by buying insurance so we simply accept the fact that if the risk happens it will have consequences we can put plans into place to deal with that after the fact but accepting just simply says we understand that there's a risk we understand what the consequences are and we're okay with it when it comes to what we actually do with risk and we saw this last time grc all works together but risk by itself it starts with the same underlying structure which is the entity the entity is simply again that record in service now that we think presents risk an application server a department a business process an individual those are all entities that could present risk to us and we address those entities by building out frameworks risk statements and risks risk frameworks are simply the idea of a categorization there are environmental risks and access control risks and departmental business process risks and there are human risks they're just a way to categorize things the risk statement is kind of the enterprise view our enterprise is at risk for a fire now you're not going to assess the risk of a fire for the entire enterprise in one shot you're going to address the risk of a fire to everything that makes up the enterprise you're going to address the risks of a fire to each facility to each data center you're going to address the risk of inappropriate access control leading to the exposure of personal information not at the enterprise level but to each application and that's where the risk statement becomes a risk those risks are generated by service now automatically and we talked about this last time where the entity type is basically the hub where we define all of those relationships the system automatically sees the entities that we need to monitor it sees the enterprise risk statements that are related to them and it will generate the risks themselves now we get the perspective of the individuals by simply sending them assessment surveys we define the assessment we send the survey out they send it back and what happens is it gets reviewed and this is a manual process one of the primary changes that i see in our clients is that they want that to be more automatic they want to take a little more of an oversight role which is what they really need and they want to say we're going to accept your perspective and we're going to update the risk accordingly and move it into a review state and decide what the response should be all of this manual work can definitely be automated a little bit but out of the box it's expected that your risk management team gets involved in the upfront configuration defining the frameworks and the risk statements building out the risk assessment to where it asks the right questions and then assessing alongside the business partner what the actual risk should be once they've submitted that assessment back into the system helping them define the risk response and the various tasks that are involved with that hopefully they're using policy and compliance and they are building alongside with that the idea of the relationship of controls to risks because that is true mitigation the idea of maintaining compliance on the control side directly impacts the residual risk that is left once we've done everything we possibly can and we'll look at that shortly when we deal with all of that we're going to come up with issues we're going to find problems that need to be resolved and that's issue remediation we deal with that with the issue functionality that spans all of grc and is very similar to the i.t issues that are defined it leverages the same functionality there is very limited use of risk inside of audit and that's why it's grayed out here risk doesn't impact audit that much especially now in the forthcoming quebec and rome versions of servicenow that will cease to be the case and there will be risk engagements that audit can then leverage and we can do engagements for risk analysis at the enterprise level with a specific perspective or sector of review there are several different enhancements to risk that we won't go into today these are advances that are currently available in orlando or will be in paris quebec or rome most of them will be available in paris with more enhancements coming in quebec and rome but the primary enhancement that a lot of companies are starting to look at is advanced risk management risk is basically from an i.t standpoint it is not as much finance related and that's where advanced risk management comes into play where being able to look at business processes and cost analysis advanced risk management lets us do a more operational view of risk the advanced grc dashboard combines all of this information with policy and compliance and gives us basically a single pane view of how risk and compliance are working together to address the issues that may come up it also will allow people to functionally address risks and compliance together from that single pane that is kind of the rcsa the risk control strategic analysis that can be done and that will be coming in paris continuous monitoring between risk and vulnerability came with orlando and it's basically the concept of if you're running vulnerability management in servicenow you can have indicators inside of grc reaching into those vulnerabilities to help you address the risk of not addressing those vulnerabilities right at this minute so we can continuously monitor the incoming vulnerability and patch management information with risk by using an indicator the grc predictive intelligence is coming in paris and it's basically the idea of hey we can tell and the system can learn to tell who an issue should be assigned to when a risk finds an issue or if someone submits a risk event the idea that a risk has been realized and we need to do something about it predictive intelligence can automatically route that to the correct assignment group virtual agent the extension for risk event creation again is part of that and it takes the virtual agent into the service catalog for risk event submission and allows the virtual agent to basically walk the individual through the submission of a risk event and then of course there's the mobile view which the ability of risk management to monitor and work with risks from a mobile platform have been greatly expanded the ability to submit of course for risk issues and risk events in the mobile is simply part of the catalog but the mobile ability to work within risk itself to take assessments to respond to risks and review the data incoming that has been added to the mobile view of risk let's go ahead and go into the demo and we're going to cover several things that we have actually seen so far and we'll jump into that again while i'm doing the demo please do not hesitate to unmute ask a question and we'll get into that be glad to answer them all right what you're looking at right now is the risk dashboard that shows the results of risk assessments and risk processing in a normal environment the dashboards are very complex we're looking at risk from multiple perspectives here and right now we're looking at it from a qualitative standpoint we're looking at whether the impact and this is what we talked about earlier we're looking at those five levels of impact very low to very high we're looking at likelihood extremely unlikely to extremely likely and we're calculating the priority basically based on those two ideas those concepts so from a standpoint of a risk manager i would want to address these nine before i address these 310 these are not going to bite me nearly as hard as these nine would when we think of very high internal risks from an inherent standpoint we're thinking of the worst case analysis what is the worst possible level of impact what is the worst possible likelihood that's inherent simply because we have a server and a network connection and a forward-facing portal to the internet that anyone can get to brings vulnerability there is inherent risk to that so the worst case analysis is always the inherent risk residual risk is our target it's where we want to be we want our residual risk to be much lower than our inherent risk because residual risk is if everything is going right if all of our controls are compliant if we're mitigating this as much as we possibly can and we've transferred as much of the liability as possible we've taken the steps to avoid what vulnerabilities we can and this is all what's left over it's the best case scenario the difference between inherent risk and residual risk without policy and compliance is basically the perspective of we've done all we can but we can't really prove it and that leads us to the third concept of calculated risk which is what's left what is our real time when you look at how the business actually operates let's go ahead and look at a risk and we're going to do so from the standpoint of the hierarchy we talked about our risk library is the framework and it's the way we categorize things and of course we have third party and supply chain threats to those we have the physical and environmental threats business service loss departmental and corporate risks these are all just categories we'll go into the physical environmental threat and we'll talk about the one that we talked about earlier and it's basically our data centers are vulnerable to physical and environmental threats what are they well there's an earthquake there's wind storms or tornadoes there's fires there are floods if i have something on the big island of hawaii i would have a fifth risk statement for a volcano but let's keep it simple and let's stick with fire from a standpoint of fire to the enterprise looking at the quantitative analysis i have a very high single loss expectancy any total loss for fire could cost me this much and that's huge however my rate of occurrence is very very low 0.4 percent when you put those two together it's going to give me a calculation but it's going to do so at the downstream level at the facility the residual is our best case we buy insurance as the enterprise we have insurance we have controls in place so our residual single loss expectancy is a much lower cost and because of that our rate of occurrence annually is even lower this is where from a physical standpoint for facilities and assets we can usually get down to the penny however for the more conceptual risks of reputation lawsuits things like that we have to go back to the perspective of the subjective what do you think we do that by simply flipping a switch and i'm going to do that right now in the administrative section are a bunch of different options one of which is the grc properties i'll slip over into the correct scope because risk is scoped and we'll go to the grc risk application and you'll see that we have use qualitative scores and use qualitative likelihood so qualitative impact and qualitative likelihood i'll go ahead and check both you have the option of not using one or the other but i have never seen a client actually do that normally for qualitative they want to stay with the perspective on both sides of the house impact and likelihood i'm going to save this this is automatically going to impact everything in the risk management system we'll switch back to infecting to make sure this goes correctly anytime you deal with grc there are multiple layers of scoping and some of the properties that you can view in here are in a different scope so just be sure that if you do end up working within grc that you're in the right scope for whatever property or whatever record you're trying to address let's go ahead and go back to the risk we were looking at and the risk statement you can see now has a drastic change in its scoring we're now looking at the simple perspective of subjectively what do you think the impact will be and what do you think the likelihood will be these are the standard out of the box for simple risk the risk roll-up and tolerance is where we talk about the operational risk that advanced risk management brings to the table this is from a financial standpoint what do we really expect at an aggregated level the financial impact of this risk will be operationally you won't see any of this unless you install the advanced risk management plug-in so we'll stay away from that just for a little while my risk scoring again is from an inherent and a residual standpoint what is the worst case impact in likelihood versus what is the best case target impact and likelihood we use the entity type to combine the two so the entity type for our data center goes out and finds the data center records and it uses the entity filter and we talked about this in our last session to find the data centers and create an entity record and the entity record is where we do our monitoring of risk and controls the entity type is the hub and we relate the entities to the risk statements at this point we can also relate them directly to a framework and if we do so then the automation will automatically relate the risk statements and you can see we obviously have policies and control objectives from the compliance side of the house additionally related to this entity type this is the where you want people to get you want them to be able to use both sides of the house risk and compliance to really mitigate risk and document that and we'll see that here in a moment i'm going to go to our entity the new york data center and looking at the new york data center we're going to see that it has four risks assigned to it and these are the environmental risks from the environmental framework the earthquake windstorm tornado and fire are automatically created because of the relationship that are defined at the entity type level let's take a look at the fire risk and you'll see that it looks very very similar to the risk statement it inherits a lot of information from its parent the category the statement itself the assessment that's to be used and the starting scoring is also inherited from the risk statement this means that every risk that comes from that statement has a shared starting perspective when we look at what is submitted by the user though that is where we get the perspective of residual risk so this one is actually in a state where it is in assess and the assessment has been sent to the respondent the respondent can be the same as the owner but doesn't have to be it can be a totally different person the person is going to respond by filling out the survey and then we're going to review our score and this is where we talk about the difference in residual that target best case impact and likelihood based on the perspective of the user and this is where normally out of the box we will adjust the residual impact the inherent impact should be pretty much the same as the risk statement and it probably won't change unless something drastic happens but the residual is where we're always going to update according to perspective now you'll notice that the inherent scores both financial and subjective are still shown and this is out of the box and normally most clients start hiding things here they don't want people getting confused and seeing annual loss expectancy or annual rate of occurrence on these forms they'll start to hide anything to deal with ale or aro they'll just worry about the inherent scores but let's see how this actually works together my inherent impact of very high but unlikely is going to give me my inherent score i'm going to change this and let's say that it is actually very high and likely so our inherent risk is high at the same time we can look at the residual side of the house and we say our best case yes the impact is moderate and our residual likelihood is kind of neutral it's just there and both cases are going to adjust our scoring this is the overall risk to the entity based on the impact and the likelihood these two basically are only based on the impact and likelihood and they won't really change based on anything else now i'm going to save this and then we'll talk about the holy grail of risk management in and that's where compliance comes into play you'll notice that i don't have any actually i do have controls that are related to this and they are compliant or non-compliant and some of them are not applicable and that's fine what that means is that my monitoring is basically coming into play for all the controls that are not applicable i have a 100 percent compliance percentage that's fantastic it's also very rare the scoring then is that because i am 100 compliant on my control side my overall risk is the same as my residual risk that's where we want to be this means that our best case is being maintained on a day-to-day operational level our compliance efforts are making basically keeping us at the minimum risk possible again this is where we want to be it's also pretty rare to have a 100 percent compliance rating for all the controls related to a risk it can be done you can get people to it but without a tool to show them they normally aren't there that's why servicenow grc really exists it's to bring the compliance efforts and the risk management to the desktop level as someone in charge of a data center i want to know that here are the controls that are responsible for keeping me compliant and i can view those and these are the controls that help me maintain the minimum amount of risk to my data centers and to the enterprise and i want to be able to see that very few applications out there have any concept of the relationship to this level of compliance and risk and will show you just how the two work together this well now this is all stuff that can be configured by the admins the risk admins not the servicenow admin but the process admin directly in production we talked about this last time where the compliance and risk admins have a lot of functionality available to them to maintain directly in production because servicenow considers it to be simple data the risk criteria they can change the values of the risk criteria they can expand the risk criteria when we look at likelihood the risk admins have the ability to say you know what i want a seven point scoring system and they can add additional options in this table and adjust the percentiles for those directly in prod if they want to our goal should always be to warn them against doing that and prompt them to work within the change management standards for their companies and say do this kind of thing in a subprod go through the standard change process to get those changes moved up into prod because you are changing the way the system works slightly even though you're just adding a data record the same thing can be done when we look at not likelihood but the impact you can add impact levels and you'll notice that both for impact and likelihood the quantitative values for impact the financial values and for likelihood the statistical values of the percentage they're still there we're not getting rid of them by moving to a qualitative side of the house but we're simply hiding them the system is still using the values behind the scenes quantitatively to do the calculations for qualitative now let me explain what i'm saying here let's go back and look at our risk the risk for fire when we look at and adjust the impact and likelihood servicenow behind the scenes is seeing a financial value corresponding to very high and a statistical percentage corresponding to for likely for likelihood it is using those two values the financial and the statistical percentage to come up with a true behind the scenes financial value and that's the annual loss expectancy that correlates to the inherent score this means that you can still look at reports and view reports that show you some of that data but it also means that people can get confused when we look at the overview and we saw this i don't know if you could see this earlier but when you look at the overview presented even using qualitative analysis there are reports provided that rely upon the quantitative data and you can see it right here the bubble charts look at the single loss expectancy that is behind the scenes for impact and the annual rate of occurrence which is the percentage behind likelihood so single loss expectancy is impact rate of recurrence is likelihood and these are still used and they can present problems if management looks at that well and says well how did you get to 2 million dollars or 1.5 million dollars of impact well we didn't because that's an out of the box measure provided by servicenow for quantitative analysis i see a lot of times those reports will be completely hidden they'll be taken off the dashboards because except at the hardware asset and facility level they can't get to these dollar amounts they can't get to the statistical analysis they'll take them off completely and only show the qualitative perspectives provided by their users the choices are also simply data points for risks it's very simple we're looking at tolerance and category category is just again a way to categorize different risks outside of the framework we can have financial risks and operational risks or reputational or legal we can have credit risks and market risks in i.t and those are just again ways to categorize outside of the framework the tolerance status we saw that as part of advanced risk but again these are simple data points that admins will have the ability to adjust directly in production if they want to again our goal as consultants is to say stick with change management do this in a sub fraud work with your admins to get the changes moved up during a standard change there are a ton of other properties and options available to the risk managers many of which are the same as compliance management when we talk about entity classes and entity tiers those are underpinning foundational concepts that all of grc uses risk managers do have some of the same visibility as compliance managers do a risk admin is automatically a compliance manager they can read compliance they can view pretty much anything within compliance a compliance admin would be a risk manager to a certain extent because the two work together so well and both sides have the ability to view anything within audit you can relate risk to vendor risk vendor risk being what are the risks of using a specific vendor if you look at how they are compliant and the risks that non-compliance on their side could impact the enterprise that's combining risk management policy and compliance and vendor risk into a single holistic view of what interacting with one single vendor can mean for the enterprise you really want to drive people to do that a lot of people use a lot of third-party risk management and vendor risk management tools and they're very comfortable with those but nothing out there will provide a holistic overview of risk compliance and vendor risk all together like servicenow does simply because they're all scoped apps that talk to each other and integrate directly within the system out of the box when we talk about our risks we talked about how our risks are scoped and we've talked about how they are actually addressed from an assessment side of the house so let's talk about how we respond to them out of the box like i said we have four different options to respond to a risk and in this case they've chosen to transfer the risk to a third party now what this means is there is a risk response task that is created let's go ahead and look at a risk that's in the response state or monitor we're going to group these by state and look at one that is specifically for a response this is for the tableau application and the inability to grow in new markets for our use of this application is the risk for the project management team and in looking at this they have decided well the impact of this is very low the likelihood is very low they're both the lowest possible and that means that basically the residual is the same i can't get any lower in this stamp case though when we look at our controls and again this is kind of demo data we want to get to where our residual and our calculated is the same from a response standpoint we can do one of four things we talked about acceptance accepting is i acknowledge there's risk and i'm okay with it i'll deal with it i'm not going to make any changes if i accept the risk i will get an acceptance task the acceptance task is basically the plan for how you intend to deal with it should it ever occur and it does require an approval by the owner of the risk and the entity it does go through a review process and you would expect and a policy exception if you're running policy and compliance to go with this because if i'm going to accept it there's probably something that i'm not going to address from a compliance side that i will need an exception for now i can do as many of these in the response state as i need to i can address the acceptance if i do it's going to throw this back into review i can say you know what let's avoid the risk and i'm going to save this and it will actually cancel that in flight acceptance task and say okay you don't want to accept it let's avoid it the avoidance tasks are very simple points of documentation how are we going to avoid this we're going to upgrade our systems to the latest version we're going to apply a patch it's going to get rid of the vulnerability if you can truly do so and avoid that risk the next step would be frankly to retire the risk if the risk has truly been avoided it no longer exists one of the two points the vulnerability or the threat is gone it's actually probably the rarest used response because truly avoiding a risk is so difficult if i choose to mitigate a risk again it's going to cancel that avoidance task and it's going to create my mitigation task exactly the same type of record looks the same and if you look at it there's just a couple of different changes to the fields but it's what is your plan to mitigate this risk and the plan can be reviewed once the plan is reviewed we can then look at any controls that need to be put in place and then work on those controls to further mitigate the risk the final piece of the response is to say you know what i realize there's risk i can't mitigate it i don't want to accept it i can't avoid it so i'm going to transfer it i'm going to buy insurance same thing if we save this and with a transfer response it will cancel the existing mitigation task and i get a transfer task now transfer does expect me to do a little bit more who's the vendor we're going through for insurance what is the contract if you're using contract management service now it's an easy way to maintain all of that information within the system but contract management again is optional and you could simply provide the plan that you're going to work with with the vendor to transfer that risk once the response has been reviewed and closed the risk will go to a review state and can then be simply put into a monitor state now unlike policy and compliance there is no way out of the box to automate the re-review of risk at a certain time frame risks are monitored until something happens that makes a reassessment necessary now we'll talk about in policy compliance how that can happen but risks are simply out of the box left in that monitor state until they're retired that's the whole process we define our frameworks and we define our statements of risk from an enterprise standpoint we associate those statements to our entity types and we let servicenow automatically create the risks for each of those entities and then we assess the risks to figure out what is truly the impact and the likelihood we respond to those risks by accepting or avoiding or transferring or mitigating that risk we then review our current standing and we can go back and reassess and re-respond or we can simply choose to monitor that risk going forward that's risk management in a nutshell but it's designed to put risk management at the desktop level what are you doing in daily operations to maintain compliance or address risk and it's designed to give the owners of the facility or the data center or the application or the asset a view into truly what they are dealing with at a daily basis that's the whole goal of grc holistically is to drive compliance and risk management down to the desktop we have just a few minutes left are there any questions about risk management anything you'd like to go over say in another session or very quickly since there are no questions we will go ahead and call it a day thank you so much for your attention i hope this was helpful and we will talk again next week [Music] you