System installationpeople maybypasscontrolspresentin systemand obtaininformationfromthe system

which is not supposed to be availafle to them undernormalcircumstances.Thus, the controls are byPassedand the system is hackedby them.
Careless or incorrectrestartingof a system afterabruptshutdownmay cause the state of transitionto be
unknownto a user. In some mailingsoftware,if a personcloses the browserwithout logging out' the next
Person can open the apflicationwithan authenticationof previouspersondirectly.
Hardwaremaintenanceactivities may be performedwhile productiolldata is on|inc, and the equiPment
undergoing maintenance is not isolated from the system before maintenance.For example, the Printer,
which is assigned to printfinancialinstrumentslike chequesand drafts, may have a stationaryof blank
Instrumentswith it. Printermaintenanceis done at this time.
OPeratormay performan unauthorisedaction for personalgains, and the system cannotdetecUstopsuch
transaction.This may lead to dataloss and modification.
OPerationsstaff may destroy hardwareand system datafor personalgains or other reasons. Data present
in the system may be lost or modified,thus affectingsystemprocessing in a negative manner.
Wrong version of an applicationmay beexecuted, if configurationmanagementprocesses arenot followed
correctly. If old sources and executablesarenotreplacedby new sources and executablesafterthe changes,
then the application may not be able to integratewith them.
Program may execute multiple instances using same transactionsagain & again, and may update the
database again and again. Transactionsonce completedmay not leave the queueand there is no controlto
protect transaction getting executedfor the second time.
Operatormay bypass installed controlsof working, andthe systemallows processing even afterbypassinI
of such controls without any notification.Controlsmay be disabled,or detective controlsmay be bypassec
and system allows them to be disabledas bypassed.
Supervision may not be adequateand people may hack partsof the System for personalbenefit or throng
negligent working patterns.The supervisor Waynot be able to detect and control these activities.
Due to incorrectly learned procedures, an operatorWay modify or delete muter mesor main databm

&om the system, and the system mayallow so withoutofferingany protectionof such infoation suc
u maining a bacp.

Data Storage MediaHandling Variousstoragemedialikefloppies,pen drives,and CI)s are handled

by softwaresystemsfor takmgbackupsor loadingdata.

Scanned by CamScanner

Risk Analysis

145

Storage.media containing sensitive data may not get adequatephysical/logical protection becausethe
oPeratlonsstaff is not trained to doso. Securityproceduremaynot be effective or peoplehandling storage
media maynot be trained as awareof security procedures.
Output may be sentto the wrong individual/terminal by mistakeandsystem allows that- The terminal may
take an action basedon sucha transaction.This is a commonscenariofor printing of financial instruments
which areexpectedto be processedon securedprinters.If user changesthe printer destinationand system
allows such change,it may break the security establishedfor the purpose.
Improperly dennedoperating proceduresin post-processingtasks may result in loss of dataor outPut.
Proceduresmay not be capableor they am not followed properly.If mediaare not handleddiligently, they
may result into lossof data.

Programming Errors Theremaybesomeesorsin programs

writtenfor theworkingsystem.Thereason
of sucherrorsmaybewrongrequirements,
wrongdesigns,wrongcoding,or insufficienttesting
Recordsfrom sensitiveHiesmaybedeletedwithout an avaifabifftyof processes
whichcan reconstructit
Systemdoesnot mainWininformationaboutwhat hasbeendeletedandwho hasdoneit.
Programmers
mayinsertspecialprovisionsin programsthat manipulatedatapresentin systems.Data may
get modi6eddueto someproblemsintroducedby software.Hard coding/instrumentation
donefor testing
maynot be removed.
Programchangesmaynot betestedadequatelybeforebeingusedin a productionenvironment.Maintenance
activitiesmayintroduceseveralregressiondefectsaschanges
mayatfect unchanged
partsof the systemand
testingdoesnot detectthem.
Changesin programmayresult in new errors because
of unanticipatedinteractionsbetweenmodulesnot
testedadequately.This is possibledueto unavailabilityof traceability matrix and impact analysisbefore
changeis not being complete.
. programacceptance
testmay fail to detecterrors occurringfor unusualinputs to the system.Acceptance
testingmay not covereveryscenarioof failure,and systemfails ata latterdatedueto somegenuinesituation
whichwasnot tested.
Program,whichmust be safeguarded,
may not be identified and protectedsufficiently. Programsmay be
changedwithout properchangecontrol proceduresin place.
Test dataandtest resultsor documentationfor applicationmay not be retained for future use.Test documentationmay not becreatedor maintainedthroughouttesting and after delivery.
Documentationfor vital programsmay not be safeguardedadequately.Lossof documentationmay lead to
problemsin maintenancewhensomechangesare suggestediu existing system.The traceability matrix may
be very useful for impact analysisbut it may be absentor may not be capableof doing impact analysis.
Programmersmay fail to keepa changelog or maintainbackupcopiesof their work or to formaliserecord

keepingactivities.Changes
are donein systemwithout properdocumentation.
Poor programdesignmay resultin critical datainitialisationto zero,or to some~
arbitraryvalue not expectedby the system.An errormayoccur whenthe programis modified to changea datavalue butonly
changes
it in one phasewhile chaugesin other phasesaremissed.
Programmay containroutinesnot compatiblewith their inteudedpurpose,which can disableor bypass
securityprotectionmechanism
preseutin the system.Theremay be someredundantcodeor somesystem
components
wherecontrolgoesby mistake.
Inadequatedocumeutation
or labelingmay result in wrong versionof programbeingmodified during
maintenance.
This may induceseveraldefectsiu an existingsystem.

Scanned by CamScanner

Operating System Flaws

Operating system is the main Layeron which the Program sits' OPefating
system provides some servicesto applicationsbeingrun and communicateswith hardware Partsas Per If Stfuct'ons
coming from the application.
User jobs may be permitted to read/write outside assigned storage area due to problems associated with
oPerating systems. Data may be written on some extern&Lmedianot expected by the aPPlication.
inconsistency may be introduced info data because of simultaneous processing of same hie by multiPle
J'obs,. and system is not able to handle such concurrency. System selected may be wrong as technical
requirements of concurrency are not defined correctly
OPerating system design and implementation erfOfS may allow a user to disable controls present Of to
access all system information by bypassing the controls, and the system does not detect it.
Unauthorised modification to operating system such as hot fixes may allow a data-entry person to enter the
Program without authorisation, and/of modify the data entered into the system maliciously.
OPerating system crashes may expose valuable information about system (such as password lfStS Of
authorisation table) to a person who is not authorised to access such information.
' Maintenance staff may bypass security controls designed and implemented in the system while peffofffling
maintenance activities. At such time, the system is vulnerable to esors Of intentionalacts. fhe system may

not detect them.

' Operating system may fail to maintain an unbrokenaudittrail and some informationfrom the trail is lost
(of modified).
While restarting after crash, operatingsystemmay fail to ascertainthat all terminal locations previously
occupied are still occupied by the same individuals.System may start communicatingwith teffflinalS
without any authenticationrequired for reconnecting.
User may be able to get into a monitor/supervisorymode without pfOpefauthofisation. Authorisation
control is nOt implemented correctly, and the system is not able to manage access COntfOlS foFdifferent
groups and users.
Operating system may fail to erase the space/freethe memory assigned to a jofl aftef noffflaVabffofffla
termination of the job Data is still availablein temporarymemory and can enter the system.

5.8.17 COMMUNICATION SYSTEMFLAWS/FAILURES

A system needs to communicatewith usefs and othef Systems. It hasto receivedata from othef systems as
well as give data to other systems in the environmentFailuresincommunicationmay be attfiflutedto the
following reasons.

AccidentalFailure Failuresin comffluflicatiOn

may occuraccidentlywhenthe systemis not Protected
&omaccidentalfailures.
. UndetectedcommunicationseffOfS from & to the systemmay fesult in incorrect/modifieddata during
communication.Data is lost, addedof altereddotingcommunicationas some Packetsate lost Of addedOT
their sequenceis alteredduringtransit.Thesystemmaynotbe ableto detecttflechangesincommunicatioll
and tries to rebuildthe messagefrom whateverit has received'
. .Infoffflationmay be accidentallymisdirectedto a wfongteffflinalOf WfOfIg system,and the messageIS Fe`
ceivedby the wfoflgpefson, who may misuseit. The systemdoesnot mute the communicationPfc.Pefly`
Communicationnodesmay leaveunpfotectedpartsof messagesin temPofafymemoryduringunantlclPate(
interruptionsin communication.These paftSmay be difected wronglyto a destinationwhefe It IS nO
expectedOf may be lost penflanently.
Scanned by CamScanner

Communicationprotocolsmay fail to positivelyidentifythe transmitteror receivermessageand those

mayget mixed' Theremaybe problemsassociatedwith encryption,codinganddecodingof messagesand
system may not be abletocorrectlydecodethemessages.

IntenfionalActs Failuresin communication,intentionallydoneby some authoriseduser/unauthorised

user, which system is not able to detectandcorrect,as the case maybe.
An unauthorisedindividualmay monitorthe communicationlines. This may happenwhen somebody
hacksa system or takescontrolof logged-insessionmaliciouslyandstartsworkingas an authoriseduser.
Systems may be vulnerableto externalusers taking controlof communicationwithin system without
.detectingsuch action.
A personmay enterthe systemby unlawfulmethodssuchas hackingandremovethe datafromthe system.
Thesystem may be unableto detectsuch incidencesandprotectthe infiltration.
Programsin networkthatswitch systems ON may be modi6edto compromisesecuritysystem. Security
compromisemay lead to exposingsystems to unplannedperpetrators
who can steal the data.Theremay
be loss of.dataor loss of controlover the system.
. Data may be changedby individualsby hackingthe lines of communicationand taking controlof the
system. Dataupdationmaynot storeor rememberthe old datain the system.Also, updationmay not need
any approvalof authorisedpersonbeforerecordscan be updated.
. An unauthorisedusermay takeover the communicationportwhenan authoriseduser disconnectsfrom it.
Many systems are notable to understandsuch changeoverandallows unauthorised
user to use the system.
. If encryptionis used, keys for decoding may be stolen by an unauthorisedperson.Data coding and
decodingmay not workproperly.If decodingdoes not work, datacommunicationwill not be understood
by the recipientcorrectly.If it is wrongly decoded,again it can lead to a communicationproblems.
User may be spoofedinto providingsensitive datato a personnot authorisedto get it. The system needs
to create a log of activities doneby differentusersin the system like accessing or copying data from system. But, if transactionsare happeningoutsidethe system,there may be very less controlby.the software
as such.
False messages may be insertedinto the system, or actualmessages may be modified or deleted by an
unauthoriseduser.This may confuse authoriseduser.The system may not be able to detect the slams of
the message entered'along with the user enteringsuch a message'.
. Messages which are confidentialin naturemay be recordedand replayed into the system. The message
may.be availableto unauthorisedpeople andany misuse is possible.
Data may be BZteredbyunauthoriseduserof the system. User may not get complete dala.

5.9.1\..NADEQU,_ATE5CHED.UL.EAND
BUD.GET
~ade(Zuate'scheduleandbudgetforproductdeveZopment
activitiesreferto manyaspectsof deveZopment
Pr9essalong-w~-cu""mer'
proces procuring
`software
fromoutsid .Someof theaspcts hisrisk.ar_
e
listed
below
--"- "' "''"'""` ' -"'
~
-' ' "'"".
.'
''-'-',...--~-.`.
.
Scanned by CamScanner

148

'~eVdlop

n-g-""-en__~~menon|
st tofn~~~-~~~
~ a~ut ~~
~d
and test the correct product whichis fit for use.
.-`--'
kof understandingof networkdiagramsrequiredfor use, and inabilityto convert effortsintoschedules
techvely OPtimisationof resourcesto get optimumscheduleandoptimisationof effortsmayi:ine.
'-)
Even If effort estimationand schedulingwork properly,yet there ay be a problemwith vailabill.tyof '
budget to Performall proposedactivitiesassociatedwith development,testingandre
"
"

5.9.2 DEVELOPMENT PROCESS/TEST PROCESS COMPETENCY

DeveloPmenVtestProcessmust be capableof deliveringthe right productto the customer.It covers adequate
frameworkof Processesused fordevelopmentandtestig, andecessary skills of developmentteam an test
team.toPerform tasks allocatedto them. If developmentprocessisnot capable,it may give producersgap or
nt gaP' If test process is not capable,it maynot be ableto detectthis gap.

ENTIFICATIONOF RISKS
has three components,viz. probabilityof_.failure_of
an applicationduring production,,ilppact of
such-failwe on the users,.andability to de-tthe occurrenceof a risk beforeor-duringits happDin
ro-bability of haPPeningof risk or impact of such risk is 0', then there is no existenceof"l`is"wen
detection ability can never be 0'. Risk cannotbe eliminatedcompletelyby any method of risk reductionbut its
Probability of happeninimpact on the user can be reduced by planningpreemptiveeffortsor risk-fighting
arrangements. Detection ability ofsoftwarecan be improvedby devisingvarious detectivecontrols as well as
training users to understand the symptomswhen risk is materialisingso that risk rating can be reduced.
msks to the final users in terms of these three componentsare identifiedin Failure Mode and Effect
Analysis (FlvfEA)' performed by the developers or experts with the help of customer or user. Outcome of
FMEA is used in developing a test plan for the softwareunder testing Risk analysis is also one way to indicate possible risks to the users so that they are aware and can take precautionswhile using the software. It
thus indicates accident prone zones' in the applicationuse.

5. I 0. I METHOD FOLLOWED FORRISKANALYSIS

An organisation
musthavea processtoidentify,defineandevaluate
risksposedbythesoftware
tofinalusersas
wellas projectmanagement
risksposedduringdevelopment
activities.
NI stakeholders
including
projectteamas
wellas usersmustbe involvedinsuchidentification
andanalysisofrisksanddecisionaboutvariouscontrols,
to
reduceprobability
orimpact,or improvedetection
abilityoftherisk.Stagesinriskanalysismaybe as follows.

Definitionof Risk

Anorganisation
mustdefineall possiblecausesof risksfacedby the usev while
usingsoftware.Similarly,theremustbe somearrangement
to definethepossiblerisksduringsoftwaredevelopmentandtestingactivities.Variousmethodsaresuggestedfordefiningrisksfor a softwareproducV
organisation.Few of themareas follows.
RiskRepoSitoly If anorganisationhaspreviousexperienceof similarsoftwaredevelopment
andusage,it
mayhavea repositoryof risksfacedby variousstakeholders
whiledeveloping
software,or risksfacedby the
userswhileusingthesoftware.Creatinga riskrepositoryforanorganisation
throughitsanalysisofhistorical
datais a very usefulway of riskidentification.
(It is said thathistoryrepeatsitselfagainand again) If one
has facedsome risk in the past,probabilityand impactcanbe assessedfromthe historicaldataavailable.
Customermayalso havea riskrepository,whichmay be sharedwiththedeveloflment
team.
Scanned by CamScanner

Brainstorming It is not necessary that all possible risks must have occurred in the past 90

that on

~eskeal~e o ae
them in the fttum' TyPically,'for some mission-critical applications,
nL
t~l~
risks, ~ `p~
~
a"dImflact.Brainstorming by experts/users can give a list of possible

TeamJudgmenf Judgment by the development/userteam about what can go wrong from the development
perspective or user Perspective can be used as a basis of finding probabilities and impact of the possible risks.
Users can derive the possible risks on the basis of analogy wi developers know`design and-develoflment
nsks' It may be possible that for every development or usage, experts r;lay not be available to help in risk
analysis. One may rely on team judgment in such case.

/nfuition Intuition/judgment by people working on the project, or the users who are or will be working on
it can add some risks to the list. This is purely on intuition/judgment of individuals, and there is no methodology available to capture it. Care must be taken that people should not become too innovative and identify
risks which have no feasibility

Expert'sJudgmentExpertsin domainor softwaredevelopmentmethodologycan contributeto the list of

risks identified. These people have betterknowledge aboutthe situationwhere applica6onwill be used and
their opinions can be used to identifyrisky areas.An organisationmust contactthe expertsavailableandmay
use their expertise accordingly.
COnSenSUSOf Team The risks may be identifiedby various means as denned above. Finally users/developers can shortlist the risks (from the possiblerisksidentified)which are feasible andmust be controlledduring software design. Managementmayundertakeriskanalysis for finalfiltrationof risks.They can revisitthe
risks identified, and studytheirprobabilityandimpact.FailureMode EffectAnalysis(FMEA)methodologies
can be used for rankingrisks.

Measurementof Risk

must_bem suren termsof probability9.{occqrren,cc,

impactof hap_-'
pening of riskson the usersand thepossibilityof detectionwhenme:-risk
is .materialising}
High p_r_ob..a_bi
and/o--i:-gh-lrh-pact
and/orlow ability of detectionassociated.w.1'th
risks indicatethat such risks must be
consideredforriskplanningbeforeotherriskswithlow probabilityand/orlow impactand/orhigh abilityof
deteeflbrL=
,_..-_-. . The processgoes throughthe followingstages.

Measuring babjljtyRisk

It may

a numberraning fromO%to 1000/oinleafing a .Probabil,ity

of happenlugof risk. Some organlsahonswith low maturltymay use termssuch as hlgh/medium/lowto

measure the probabilityof risk. Any methodappliedshouldbe consistentand sufficientfor the purpose.
probabilitymust be a possibilityof happening
of a certainevent,andriskrepositoryhelpsin identifyingsuch
possibilityif thereis historicaldataavailable.Sometimesexpertsjudgmentor brainstorming
may not give a
close probabilityas it is basedon judgment,anduse of `high/medium/low'
may be recommended

k Impactof the riskmustbe measuredin termsof loss to an organisationdue to materialisa-

tn of rik. It would be advantageousto definetheloss in termsof money value. Some risksmay not have
directmoneyvalue andpeoplemayprefertodefineimpactin termsof `high/medium/low'.If the organisation
has a risk repositoryavailable,measurementof impactbecomes easier.
The matrixin Table5.1 expressesrisksin termsof probabilityandimpactof such risk.

I) High risks: Whereverprobabilityandimpactbotharehigh, itrepresentshighrisksand mustbe Prevented

/m~igated first. If prot;abilityremainshigh, thoughimpactmay be medium/low,it is still cons'deredas
highisk. Whereve probabili`ty
may be mediumbutimpactis high, it is also consideredas hlgfl risk'

j
]

150

SOFTWARETEST/NG:PrincipleSe
Techniquesand Tools

2) Medium risks: Whereverprobabilityand impactbothare medium,it is consideredas mediumrisk. These

may be mitigated if the customerinsists on such actions.Wheneverprobabilityis mediumand impact is

low, or Probabilityis low but impactis high, it is also consideredas mediumrisk.
3) Low risks: Wherever probability is low and impact is medium/low, it can be considered as low risk. There
may be contingency plan for such risks.
Table5.1

'

H - M. L matrix

~Probability"""`.""`""`""..'-."'"""-"`""`
/mpad

~'

'-"'.Hjf{ih.'

High

Hig.'h:

Medium

High `

Low

High

"

- '

Medium

High

Medium

"'

Low

Medium

Low

Medium

Low

OetectionAbility-Abilityto Detect Whenthe Riskis Rea{jSjngIf theriskcan be seenwhileit is happen..

mg' or If it gives some warningor indicationbeforehappenin its detectionabilityis consideredas`l;igh.
Userscan be safeguardedtosome extentin case of beingwarnedwhenthe riskis apparing.If theriskoccrs
suddenly'It has moreratingas the impactis sudden.Thus,detectionabilityratio arerev rsed.In case of
risk wheredetectionabilityis veryhigh,theratinggivenis verylow On theeotherand,in case of riskwhere
thereis no chanceof detection,ratinggivenis very high.

Risks are measuredand rankedas per Risk PrioritisationNumber(RPN)' or Risk Identification

Number(RlN)'. Mathematically,
riskscan be categorisedas perquantification
of risks.
msk formula = probabHityof occurrenceof fish x impact or loss x inabHityof detection
RPNIRIN- P x I x D
Risks with higherratingsneed to be plannedfor handlingfirstwhile riskswith lowerratingsmay be
accepted as it is dependingon management'sdecision.

5.11 TYPES OF SOFTWARE RISKS

Risksassociatedwith softwareapplication
use arenumerous.
Theychangefromapplication
to application,
fromcustomerto customerandfromtimetotime.Evenif therisks,identifiedaresame,yettheirprobability,
impactanddetectionmaydifferconsiderably
fromcaseto case.Somerisksaretimedependent.
Followingis
a list of few risksassociatedwithimplementation
of softwareapplication.
Incorrectresults may be producedwhileprocessingdatausingan application.Wrongresultsmaybe dueto
algorithmproblems,rounding-offerrors,designproblemsandso on. It mayaffectvariousdecisionstaken
by the user on the basis of data processing.
Unauthorisedtransaction can happen when somebodywho is not authorisedto performsome action is
capableof crossingthe defensewalls and enteringthe system.This can happendue to some Problemsof
_-"
"' ..,"
Scanned by CamScanner

de$ig.n and deneloflmentthroughrequirementswherethe system is notprotectedadequately.jncomfatible

,reqult~
meats and design may lead to variousdefects of securitylapses.
"
sablhty of the system is very importantfactorwhile deployingit. Peof le giving requirements
and creating
oeslgns may not understandexactlywhattheuserswantorwhethertheyarecapableof usingthe system.If the
commonusers find it difficultto use the system,i.e. if usabilityis poor,it can hamperusageof the systcln.
Performance level of system may be unacceptabledue to optimisationproblems, memory leakages,
bandwidth issues, etc. If the response of an aplication is weak, users may not preferto work with it. jf
the resPonse is much fasterthanthe requiredspeed, it can also createproblemto users. Risk of rejection
of such a system by the users is very high.
System may be wlnerable to outsideattackslike viruses,Trojans,andworms.Althoughfull-proofsecurity
is impossible, yet sufficientlevel of defense is necessaryto protectdata from pilferage,loss, etc.
Systemmaynot workwithotherhardware/software
availablewiththeusers-this canbea compatibilityissue.
Theuser may not preferto changethe environmentwherehe is comfortablefor the sake of an application.

ANDLING O F RIS KS IN TESTING

Every organisation faces many risks while using/creating software for business purpose. Users may face
several risks related to inability of an application to satisfy their needs. Development organisation may face
project management risks while user organisation may face user related risks. Here, we will not be dealing
with project management related risks as these may not affect testing approach directly. We will be dealing
with risks associated with users in terms of loss or difficulties faced by them. In risk planning, an organisation
has to decide the strategy of handling the risk associated with usage of software. Risks can be handled in five
ways, as given below.

5.12.1 INH ERENT AND RESIDUAL RIS KS

Thereare variousrisksassociatedwithsoftwarerisk.Inherentrisks describeall risksinducedin the system
due to some of the reasonsdescribedabove. Theyare presentby defaultwhen we decideany particular
approachof implementation.
Residualrisks are therisksremainingin the systemafteran organisationor
customerdecidesto takeactionsto reducethe probabilityor impactof the risk. Riskscan never be made
zero' unlesstheorganisationdecidesto bypasstherisk.

5. 12.2 ACCEPTANCEOF RISKAS ITIS

An organisationmay list the possibleriskswith probabilities
and impacts,but withoutany action plan to
preventor mitigatetherisks-thusacceptingtherisksas theyare,as perthedecisionof themanagementfrom
customerside. Thisis a managementdecisionbaseduponcost-benefitanalysisof therisk and possible controlsto avoid it. The natureof therisk playsthe majorrole in this decision-if therisksare uncontrollable
(suchas naturaldisasters),or if risk controlis economicallynot viable,thenthe managementmay decideto
accepttherisk evenafterknowingits probability
andimpact.
No furtheractionsarerequiredoncetherisksareacceptedby themanagementor customer.Thereasonfor
acceptanceof riskmaybe documented
so thatconcernedpeoplemayreferto it in future.

5.12.3 BYPASSING/AVOIDINGRISK

Bypassing/avoiding
risk involvessteeringclearofany particulareventleadingto the risk, by changingthe path
opproach which is responsiblefor inducingrisk. This can be one of the outputsof risk managementdecision._

cannea oy lamcanner

where cither risk is uncontrollable or risk control is economically not viable. If software imPlementation is a
~isIn_anagement may decide to continue the existing manual operations.

4 RISK PREVENTION
Preventing risk can be useful only if probability of failure due to risk is signi6cant. When the Probability of
failure is very high, it represents a potentially harmful event. By preventing the occurrence of such an event,
the Probability of failure can be reduced to an acceptable level. prevention works better than cure' may also
be used when there is no possibility of reducing impact, if the risk materialises.

5 12.5 RlS K M ITIGATION

Risk mitigation can be useful when the impact of risk is high`but probability of happening of such an event is
not so high'if Probability is not very high but the losses due to materialisation of risk are very high, then there
must be some mechanism existing to reduce the possible impact when such risk becomes a reality It can be
aPPlied even when there is no possif inly of reducing probability. A very common example may be a natural
disaster where it is beyond human capabilities to reduce probability,but impact may be reduced substantially
by devising plans accordingly.
When both probability and impact are moderate, then a combination of preventive and mitigation controls
can be applied.

5.12.6 DEFUSING THE RISKS

Sometimes,it may be difficultto avoidthe riskandreduceits probability
and/orimpact.Acceptanceof the
risk is also difficult--suchinstanceshave no solutionandhence,area crucialconcernfor an organisation.
In such cases, an organisationmay try to diffusethe riskby takingsome actions.Keepinga backupof the
operations,buying insurancecover,andmulti-siteworkingare some of the ways in whichthe organisation
can diffuse the risks.

5.12 7 CONTINGENCYPLAN
Contingencyplanningis required
to knowwhatoneneedsto dowhentheriskmaterialises.
Afterplanning
to
reducetheprobabilityof a riskthrough
preventiveactions,andtoreduceitsimpactthrough
mitigation,
it can
be possiblethattheriskbecomesa reality.Onemusthavea runaway'planin ordertomanagetheriskwhen
itemes
realityThis maybe a damage-control
mechanism.

TYPESOFACTIONSFORRISKCONTROL
MANAGEMENT
Whenan organisationdecidesto controlthe risks-eitherprobability
or impactor both-or triesto imProvc
detectionability,then it appliesdifferentmeasures.msk reductionmeasuresarecalledas controls.Control
are of two maintypes dependinguponthewaytheyare aPfllied'

ManagementControl Controlsappliedby the managementsdecisionare managementcontrol!

Thesemay`beappliedmanuallyorthroughthehardware/software
devisedforfflePurfiose'
Manag.emenf
coll_

troldefinesthe~licies andstrategies
of doingthings,in orderto avoidrisks,orto reducetheir~mct wmlI
theymaterialise.Managementcontrolsset thefoundation
on whichapplication
controlmaywork`(ienerau
managementcontrolsare preventivein nature.'
Scanned by CamScanner

hysiAPc1~
tieOmsnDCOntf
ol APPlicationcontrols are exercisedby the hardwarclsoHwareor by somc
thundee
wor inc ~~~~ee

yb

~ ae tn

os'somThue a~

thoua
~ o re

Controls can be FurtherClaSsjficdas ShownBelow

e cPf rotjs oliecControlsThecontrols which canprevent the happening of risks are termed as prevene

erallyar

ae

le~ drd~o

e,m

nag am

~ect \/Ce~

(such as code of conduct, policies and procedur' s) serve the purposof preventive contr The preventive
controls must follow Poka Yoke' methodology so that risks maynot occur in the first place,

CommonTypesof PreventiveControls

*
*
*

Authorisation before entering data into the system can reducethe probability of wrong data entry.
Data entry in the system with validations applied at the level of data entry.
Input validation using some automated or manual check to prevent errors.
Pre-numbered forms are used in excise and sales tax invoices,so that there is control over outputs.
Error messaging of preventive type which preventsanything wrong from being entered into the system.
Tool tips. Some applications provide a facility that when the cursor hovers over a particular control,
tool tips are displayed For example, if a cursor hovers over the first icon in the tool bar of a Word
document, a tool tip appears which says Nw Blank Document'. Tool tip' is a common terminology used
by developers and testers.

Poka Yoke Poka yoke is termed as positive con6rmation' or `fail-proof arrangement' where no risk will
be permiued to hit the common users. Poka yoke means making an arrangement so that nothing can fail. It is
supposed to give consistent results and does not have human-error factor.

Indicative/DetectiveControl Thesecondlevel of controlsis indicative/detective

controls.The

wntrols whichindicatethatsomethingunnatural
is happeningandthus,thereis a needforthe personlentity
responsible,to takeactionsto controlthe damagehappeningdueto materialisation
of therisk are indicative
controls.A simpleerrormessage,`thefile deletedfromtherecyclingbin will not be availablein future',is a
kindof indicativecontrol.

CommonTypesof lndicOt,"ve/Detedive
ContrOl
. Datatransmissioncontrolwheredatasend from one placeto anotheris talliedto find if somethinghas
beenlost/gainedduringthetransmission.
. Control/hash
totalsareusedto comparethetotalsof transactions
takingpartin processing.
Errormessagingof detectivetypewheresomethingwrongis indicated.
. Reactive/Corrective
Control Reactivecontrolsreactto the adversesituationdueto happeningof
a riskto controlthe damage.The fuseinstalledin anelectricalapplicationblows off when voltagefluctuates
to save the equipments;thisis a kindof reactivecontrol.Reactivecontrolmay work in conjunctionwith
indicativecontrolwhereindicativecontrolgives a thresholdto activatereactivecontrol.Reactivecontrols
'areof twotypes,namely,

Auto-Reactive Control Auto-reactivecontrols act withoutany interferenceby human elements.

Generallywhen a detectivecontroldetectsa problem,thentheauto-reactivecontrolgives a thresholdto an
eventto controlthe damagedueto riskrealisation.
Scanned by CamScanner