CHAPTER 2: THE ISO19770-1:2012 FRAMEWORK

Whilst this booklet should support/pique your interest in SAM and the processes required to make it an effective business practice, I would strongly recommend obtaining a copy of the Standard itself – available from the ISO website: (www.iso.org). Please ensure you obtain the correct standard; −2 concerns itself with the rules pertaining to Software Identification Tags; −3 is centred on the specifications relating to Product Use Rights.

ISO19770-1 focuses on 27 processes/activities which it deems core to addressing effective software asset management – these are divided as follows (see Figure 2, Figure 3 and Figure 4).

Figure 2: Organisational management processes for SAM

Figure 3: Core SAM processes

Figure 4: Primary process interfaces for SAM

Control environment for SAM

Corporate governance process for SAM: This process should be the ethical heartbeat of your SAM programme. It is required to ensure that corporate- and director-level understanding is achieved in regard to software asset management, and that appropriate action has been taken to address SAM in the organisation. From here, a company declares that its staff will respect and abide by the licence terms and conditions, and that software usage will be in line with the express purpose for which it was purchased. Reference to disciplinary procedures in the event of deliberately flouting this policy should be undersigned by a director as a minimum.

Roles and responsibilities for SAM: Hopefully, once you have embarked on a SAM programme, tasks will not always be the sole responsibility of one individual. Equally, listing the processes required to complete a SAM project and move it into BAU (Business As Usual) status will help determine ownership of specific tasks. Either way, a formal document highlighting who does what will be pivotal to the success of any SAM programme. RACI documents (Responsible, Accountable, Consulted and Informed) can go a long way to helping recognise who should be assigned various tasks.

Policies, processes and procedures for SAM: This document should act as an operational expression of a company’s intention as to how it wishes its staff to treat software – covering the life cycle headings previously mentioned:

• requisition
• acquisition
• delivery
• cataloguing
• testing
• deployment
• change management
• upgrades/downgrades
• re-deployment
• storage
• retirement.

Some organisations have their staff sign documents acknowledging the company’s stance on how to deal with software – others are too large to undertake such a task, and so build them into Terms and Conditions of employment; making it a HR function to ensure that they are read and understood. ISO19770-1 does not prescribe how this should be done; merely that it is.

NB: It is worth noting that you may require several versions of this document, based on the varying IT levels of staff in your company. For example, a zero-tolerance policy which does not allow staff to install software, could severely hamper systems administrators and developers. Contractors, too, may be limited to certain networks; they should understand this and acknowledge that attempting access to other company networks may not be permitted.

Competence in SAM: A SAM programme should always ensure that any staff employed to oversee the SAM programme know what they are doing. Again, ISO19770-1 does not offer a definitive list as to qualifications or experience required by such staff. However, due regard should be given to the following criteria:

• former experience
• knowledge of any systems being used in the SAM programme
• licensing expertise
• knowledge of legislative, regulatory and/or best practice initiatives in the SAM arena.

SAM is a reasonably dynamic discipline – systems are upgraded, legislation gets updated, and licensing models change with alarming regularity. So, an employee’s willingness to learn and stay on top of such changes is worth its weight in gold. A company, too, should ensure that it does not put all of its ‘SAM eggs’ in one basket – factor in resilience within the skill-sets required to address multiple vendors (this will also help to address holiday cover too). Also, ISO19770-1 makes mention of reviewing what constitutes proof of licence at this point (at least once, annually); I suspect, so that such information becomes and remains ‘corporate knowledge’.

Planning and implementation processes for SAM

Planning for SAM: The scope of a SAM programme is often one of the most lightly considered aspects of many SAM programmes I have seen, and the one most open to abuse when it comes to the concept of project creep. Often as not, a SAM programme is hastily convened to address an impending vendor audit; which might cover a subset of a wider organisation for that one vendor. Pretty soon, other vendors’ software gets added to the project, but this could be after the system used to capture inventory data has already been purchased; only to find out that it doesn’t capture the inventory data of those subsequent vendors! Very definite and real goals need to be stipulated, with the proviso that, if scope exists to achieve wider capture, then such aims can be addressed at a later date.

A quick delve into the world of operations management will help with the creation of SMART objectives when planning for SAM:

• Specific
• Measurable
• Achievable
• Realistic
• Time-based.

These goals, aligned with the roles and responsibilities highlighted in the control environment for SAM, should act as a solid foundation for the kick-starting of a SAM project. Please note: I use the word project here; once the planning and implementation processes have completed, the SAM agenda should change from project state to BAU.

Plenty of books have been written concerning best-practice project management techniques (including risk analysis or Six-Sigma, for example), and borrowing techniques from these disciplines may well help you gain a greater understanding of what is to be achieved. Such achievements should be in alignment with the corporate governance and SAM policies, procedures and process objectives, mentioned above.

Implementation of SAM: Once a time line has been established against the deliverables mentioned above, then a clearer understanding will emerge as to how and when such deliverables will be achieved. Depending on the size and scope of your SAM programme, you could have many systems integrating across tens of thousands of devices, spread across multiple time zones, catering for a range of software vendors. The interaction required in bringing inventory data alongside purchasing/licensing data (and perhaps some Active Directory/user data for good measure) could prove to be a major exercise in data logistics. The GIGO (Garbage In – Garbage Out) acronym was never truer than in SAM. Quality controls around the importation and manipulation of such information needs to be built in to establish faith in any conclusions arrived at by the SAM programme. ISO19770-1 refers to the ‘Plan-Do-Check-Act’ cycle of implementation to ensure that a review process offers an assessment of implementation progress.

Monitoring and review of SAM: This is the portion of ISO19770-1 that seeks to offer a health-check on the implementation of any SAM programme. Again, the Standard does not stipulate how this should be done, but it does advocate (at least) annual reviews to ensure that the SAM programme is effectively delivering against the objectives stipulated.

Continual improvement of SAM: This aspect of a SAM programme lends itself very well to the scope widening previously mentioned. Your original target may have been to audit and reconcile one vendor, or one geographical location within a company or conglomerate, but that scope may widen once the project phase ends. Proficiency in capturing another vendor’s inventory data may be a subsequent target, or perhaps you are considering investment in a system that maps product use rights via stock-keeping unit numbers imported from inventory data, to offer an easier route to licence optimisation. Quality assurance flags within processes can often be aligned to function steps that provide metric data, or offer an ‘exception loop’ to handle/capture errors. Any improvement should be assessed against the SAM policies and procedures and against their adherence to ISO19770-1.

Inventory processes for SAM

Software asset identification: ISO19770-1 seeks to ensure that an organisation is fully conversant with all elements of software that could be used to identify and justify its purchase and installation in a company. The ISO Standard offers guidance on what those elements might include, but ultimately it is down to the organisation concerned to find out and confirm what those assets are. These might include:

• hardware characteristics that could influence licence consumption (e.g. quantity of processors, core-count of processors)
• all installed software
• software versions
• patches and updates
• licences
• proof of licence documentation (including purchase orders, invoices, original packaging, original documentation, etc.)
• licensing models
• master versions and distribution copies of software.

Meta-data surrounding software required by ISO19770-1 includes:

• unique identifier
• name/description
• location
• owner
• status (development, test, production, etc.).

Software asset inventory management: Having taken the time to understand the relevant data and meta-data required to recognise and manage your software assets (above), ISO19770-1 then requires you to document how that data lends itself to the storage and maintenance of reporting on such software throughout its life cycle in the company. This includes any contracts and/or documentation that supports and justifies the use of your software, such as it is deployed. Electronic copies of physical-based evidence would be a good move at this point.

NB: Software vendors are not duty-bound to accept scans of physical documents; however, they are very difficult to dispute in a court of law. I mention this, because I was asked one time: ‘If I scan all my licences electronically, does that mean I can shred the originals to save space?’ A software vendor might argue that such a scan was created in a word processing package (i.e. faked) – do not leave yourself open to that risk.

Software asset control: This is a major security portion of ISO19770-1. Namely, a process or a number of processes are required to ensure that software assets are kept in their intended state, and that a change record is kept when their status changes; including who or what system changed their status and when. This also includes moves to differing locations for software assets, including the development stage of software assets and a baseline snapshot of software assets once a title enters into production.

Verification and compliance processes for SAM

Software asset record verification: Further to establishing processes around the control of software, which note any state changes from development through to deployment, ISO19770-1 also calls for a subsequent process to ensure that the methods and means by which that data is captured offers a fair and accurate reflection of the software deployed, and that appropriate security is applied to such records, so that they can offer a trusted source of information. This might appear to be overkill; however, at the heart of such a concern is that a company is in a position to trust the data it presents to either internal or external examiners. Some very sophisticated solutions will allow very tight controls governing access rights to a dedicated software asset management system; alternatively, it could be that summary data is compiled and presented via a commonly accessed spreadsheet. Such a process seeks to ensure that, whatever method is used, it is done so by the right personnel and, subsequently, afforded appropriate security to prevent tampering.

This particular process within ISO19770-1 is quite specific in its outcomes, too, calling for:

• quarterly audit and reconciliations highlighting any unauthorised installs
• six-monthly hardware audits
• six-monthly audits of definitive master versions and distribution copies of software; highlighting any exceptions/anomalies identified
• six-monthly audits of software builds; with any exception reports
• an annual audit of any physical stores of proof of licence; highlighting any exceptions, including software contracts
• an (at least) annual audit of underlying licences to be undertaken to ensure that double-counting is not taking place (i.e. some licences will allow for multiple installs of software, but justify them with a single licence)
• and perhaps most importantly, a remediation plan to address any shortfalls highlighted in the above checks.

Software licensing compliance: Whilst the previous process/processes were created to account for the physical evidence to compare against installs, this process seeks to introduce the licensing knowledge required for a truly effective reconciliation. This process calls on companies to ensure that any such software deployed by a company is properly licensed and used in accordance with the terms and conditions of that licence.

So, the process should deconstruct the ‘how’ of a software title deployment in your company from the licence, and be able to compare that to the install base for a software title. ISO19770-1 calls on this activity to take place at least quarterly, including producing a report highlighting the reason for any discrepancies and, finally, that an action plan is executed to remove the occurrence of any anomalies.

Software asset security compliance: This process seeks to enforce and check upon any security processes created around the protection and management of software assets. So, at a very base level, it could be that a sign-in/sign-out log, created to monitor the use of master versions of software (e.g. physical disks), was being correctly updated, and can be aligned to any installs that might have been made during a checked-out period for a software title. It might also verify that the person who checked out that master version was authorised to do so. ISO19770-1 calls for such checks to take place at least annually.

Conformance verification for SAM: Having determined what your SAM programme will entail, you are also required to ensure that a process is in place to verify that it adheres to the demands of ISO19770-1. This annual assessment should document that such checks are taking place, and also that any corrective action to address exceptions has been successfully completed.

Operations management processes and interfaces for SAM

Relationship and contract management for SAM

This element of ISO19770-1 is where your business analysis (both internal and external) pays dividends. Having embarked on a SAM programme, you should be ensuring that:

• the SAM programme has clear and defined objectives of its own
• those SAM programme objectives support wider IT operations and strategy
• those IT operations subsequently support business operations and strategy.

Factors to consider when drafting goals for relationship and contract management for SAM might include:

• Who are our customers (both internal and external)?
• What might they reasonably expect from the SAM programme?
• What can we provide them?
• How frequently will they expect such information?
• How quickly can we provide it?
• What format is acceptable to them?
• Does the information provided qualify and protect our organisation’s position in regards to software asset management?
• What related services (e.g. support and maintenance contracts) require the attention of the SAM programme to support this organisation’s underlying software position?
• Do we rely on any third parties for the provision of our data?
• If so, are they fully conversant with the importance and timeliness of providing such data?
• Is all contact information for customers (both internal and external) collected and up to date?
• Do policies and procedures exist, defining roles and responsibilities for supplier management?
• Are terms of reference in place for those individuals charged with managing such relationships?
• Does an invitation to tender for the supply of software and services form part of the procurement process?
• Is there a formal review process in place to assess the quality of service(s) provided by vendors, with documented conclusions and activities ascribed concerning any action to be taken?
• Does an annual review assess whether the software (and any related services) purchased are meeting the needs of the business for which they were originally purchased?
• Do we review future software needs?
• Do we currently review the terms and conditions of contracts as they apply to the purchase and deployment of software?
• Do we have a document management system that provides adequate security/privacy for those contracts?
• Do we review (with six months’ notice) all contracts prior to expiry?

Clearly, looking at this expansive list, we can see that a lot/most of the questions pertain to procurement/contract department work. This is why SAM is not just an IT-based project; and why it also takes more than a degree of tact to see such a project through to a successful conclusion. Gaining buy-in from all parties prior to the programme launch is vital, and the higher up the ladder such endorsement for the programme comes, the less likely various departments might be to try to shy away from their responsibilities. (I’m sure we’ve all worked for companies where we can think back to a department or section of the office that lacked a certain ‘business discipline’. Please think back to the former example I offered about the trial-ware installed in a company; £500,000 is not the kind of slush fund anyone needs to advocate because apathy is the word of the day.)

Financial management for SAM

Financial management for SAM, as seen within ISO19770-1, is meant to provide a ready-to-use methodology to generate total cost of ownership (TCO) and return on investment (ROI). Just by looking at those two statements, we can determine that engagement with the financial division of a company is going to be pivotal, if the SAM programme is going to offer any meaningful or tangible fiscal information off the back of an audit and reconciliation.

Questions to consider when integrating such information might include:

• What level of finance/expenditure data will be required?
• Who will require such data?
• How dynamic should that data be?
• Who is handling invoicing?
• Does the person handling invoice data understand the difference between licence quantity and purchase quantity? (Some licences ship as multi-packs, as an example.)
• How is purchasing data going to be used/entered, and then compared to installation data to offer a fiscal evaluation of TCO & ROI?
• What format will the financial reports take?

On an ongoing basis, we need to also ensure that such reports (again) offer value to the business, and support it in its decision-making processes. This immediately brings us back to consideration of the following: What are the best purchasing options for software acquisition? Can our financial management of such purchases be shown in the context of a wider IT budget?

Whilst finance can be quite precise in its outcomes (governments all over the world can be quite exacting about what information is provided for accounting data, tax returns, etc.), the means and methods by which we derive such information can be as varied as any route through a maze; and this brings us neatly to the observation of how we view IT within a company. Does your company view IT as a utility? Is it charged for by consumption? Alternatively, if your company is spread about the globe, do you adhere to national boundaries as a means of delineating and managing your IT spend? Alternatively, you may have a corporate structure that dictates what IT assets are fiscally allocated where, and so cost-centres can transcend national boundaries.

At the end of the day, ISO19770-1 does not prescribe a dedicated course of action, but what it does allude to is having a plan in place. Bear in mind, that to get this SAM programme off the ground, you might well have gone to senior management, and made a ground-shattering pitch about the potential savings that the programme could deliver – this has to be evidenced – and done so in the bounds of corporate structure. Understanding the financial rhythm of your company will undoubtedly give you a clearer picture of how to correctly present and manage cost-data for software.

Service-level management for SAM

A small, but ever so valuable paragraph within ISO19770-1 (that again, regrettably, is all too often overlooked), highlights aligning the SAM programme to any service-level deliverables that currently exist within your company. Your primary driver in the short term, for such a programme, might be to counter a vendor audit, or to make savings on unused software, or even merely to give you a better visibility of your IT estate – however, to ensure that your SAM programme doesn’t remain a project, you will need to ensure it has traction in the medium to long term within the company. There is no better way to do this, than to examine your existing IT functions (and perhaps some non-IT functions, too,) to see how they could be improved by SAM.

Once established, ISO19770-1 seeks to ensure that a process exists to assess that the SAM programme is actually meeting those objectives and that, if it is not, non-conformances are documented and action is taken to correct any shortfalls. The Standard advocates (at least) quarterly meetings to assess the delivery of such services to support any service level agreements. Depending on the importance and urgency of those services, you might wish to make those meetings more frequent.

If you are seeking an adjacent standard or framework to operate with, then integration with ITIL,^® or even ISO20000, may be a way forward.

Security management for SAM

Managing security within all SAM activities could lead you to spiral into thoughts about just how far the SAM programme is accountable for information security. Thankfully, an adjacent ISO standard exists that offers an excellent route to implementation – ISO27001. To offer such a scope or boundary, consider what you believe to be core SAM activities, including physical access to physical and electronic media; user access to any systems involved in the SAM programme; and that documentation exists to demonstrate that a security management process is being adhered to.

ISO27001 offers an excellent approach to kick-starting an information security management system; it does this by going through a risk management assessment. If you are looking to win over management as to the need for a SAM programme, then this, too, could be a very useful exercise in collecting the necessary information which can be used to promote ISO19770-1 adoption in your company. Licence compliance is a cornerstone requirement of ISO27001.

Life cycle process interfaces for SAM

This is where ISO19770-1 gets quite specific in seeking to ensure that the SAM programme is capable of keeping up to date with the flux that is IT management. Specifically, the Standard is looking to ensure processes exist for:

• change management
• acquisition
• software development
• software release
• software deployment
• incident management
• problem management
• retirement.

Change management: If a change is requested that could alter a SAM-related asset, then it should be documented, prioritised, approved, actioned, assessed and periodically reviewed against self-determined QA (quality assurance) criteria. These steps do not have to be onerous for your organisation – it could be that you have a shopping cart menu on an Internet browser that will handle the majority of such steps for you. A word of warning here: you may have to tailor your change management process, depending on the value or quantity of software that is experiencing such a change, so a ‘one size fits all’ approach would not be advocated in this instance (e.g. a single install of Adobe Reader^® vs. a version upgrade to Microsoft^® Office^® throughout the business).

Since its publication, and the maturing of such terminology used within its pages, the concept of change management could also enshrine changes to personnel, or, indeed, changes to hardware that could alter the state of a licence requiring precise specifications pertaining to CPUs (as an example). The best rule of thumb to offer in this instance is, if a change can alter a licence position, then a process should encapsulate how to effectively document and manage that change (including any exceptions that might occur).

Acquisition: In an unruly and uncontrolled IT environment, this is where (potentially) the biggest misunderstandings (and problems) arise. Well-meaning, but mis-informed, individuals think that they are doing the decent/most expedient thing by buying software on a company credit card and installing it locally. Not only could this be the most expensive means of purchasing software, it completely circumvents any IT manager’s hope of control (not to mention financial control, too).

Acquisition should allow for the checking of budgets, to ensure the purchase is fiscally permitted and that the appropriate channels have been used to request the software and approve the request. Also, that the software being requested conforms to an Approved Software List; or that software not on the Approved Software List has been managed within the processes designed. A further check should also take place to assess whether or not an existing licence can already be allocated. Finally, ISO19770-1 appreciates that a degree of lag may exist between deployments (for those lightning quick installs that have to be done yesterday) and the purchasing records that will eventually catch up. Your process should account for such discrepancies – the reality of this is that an IT manager is then not chasing down a user, or a department, for deploying software that he doesn’t yet have the evidence in place for, to account for the install.

Software development process: ISO19770-1 isn’t overly verbose when it comes to controlling software or software-related assets here; not least because controls and policies that might be deemed necessary for standard users could be viewed as counter-productive, or even restrictive in the development community. Suffice to say, the Standard makes reference to the fact that consideration is given to standard architectures and configurations, and licence constraints and dependencies when designing software.

As an IT manager (and in regards to discovery of software), what you may wish to consider is leaning on your naming convention – if you are in a position to name systems that developers use with a marker denoting that they are used to cut code, then it may prevent alarm bells going off within your SAM system when numerous instances of very expensive software titles spring up with little or no notice. The example I offered concerning the slush fund of £500,000? That was a latest release of MSDN (Microsoft^® Developer Network) – enough said!

Software release management process: Again, ISO19770-1 does not overly prescribe the dos and don’ts of releasing software; it merely states that the objective of any policy/policies is to support SAM requirements. A formal release management policy, should, as a minimum, cover:

• a testing environment to test all software (including patches) prior to formal release
• that any deployment of software (including patches, hotfixes, etc.) are scheduled and agreed to with the business
• that any software deployment is formally endorsed by appropriate management
• that software deployment is monitored and recorded, with any notes/exceptions, etc. being relayed to incident management
• that deployment records are periodically reviewed (including failures, as well as successes).

This element of release management may give you the idea that such a policy was designed with vast deployments across multiple networks, using specialist deployment tools to carry this out; and you might not be wrong in such an assumption. However, if you take this policy a little further, what it will also grant you is an intended position of your IT estate. After all, if the release management wasn’t formally authorised, what are the unauthorised titles doing on your systems? I would suggest linking any release management policies with an inventory collection policy of some kind, so that a quality assurance assessment can be made:

• Has this software been tested prior to formal release?
• What is the title, version, edition and release of the latest software release?
• Who are the intended recipients of this title?
• Who has endorsed this release?
• What business function does this release satisfy?
• What are the scheduled date(s) and time(s) of this release?
• Have incident management been pre-warned of the forthcoming release?
• Who in incident management do we pass the results of the release to?
• Who actually received the software?
• Does this list match the intended recipients (above)?
• Did anyone beyond the scope receive the software? If so, why?
• What is the location of the release management report (for future analysis and comparison)?

Considering your own unique IT environments, you may well have extra points to consider, including duration of installation; cross-charging requirements; if the title is brand new, nominating a designated champion for that software title within your company; also, if the title is brand new to your organisation, then perhaps it should be added to your approved software list (and, indeed, does it replace an existing title?). Such questions are designed to get you thinking around what elements of control and management you want in place, to offer you the best chance to know what is taking place on your IT estate.

Software deployment process: Having gone through the above-mentioned steps, you might be scratching your head wondering what the differences between release and deployment actually are – well, perusal of the ISO19770-1 Standard suggests that the deployment process is more operationally weighted than the release management section. The formal policy should include:

• That the distribution of the aforementioned release is formally approved (e.g. the release of Adobe Premium CS6^® could be approved by the nominated representative within the company, but that the actual deployment would then be approved by the person who looks after SCCM – System Centre Configuration Manager – for the company).
• A rollback procedure or method should also be detailed in the process, so that in the event of a failure, existing IT systems are not handicapped by trying to repair defective deployments.
• All security requirements should be addressed; including physical and electronic access to the software being deployed – before and after deployment. For the information security gurus out there, consideration, too, should be given to what access the software provides for users, as it is deployed throughout your systems (and equally, the ingress provided to your IT network by that software).
• A refresh should be undertaken of all associated meta-data pertaining to the software title, including custodianship/ownership of the software title, and any changes to the status or location of the physical or electronic copies of the master copies.
• As suggested above, a check should be made to ensure that the proposed deployment matches the actual deployment.
• A periodic review of the deployment (both successes and failures) should take place.

It might be worth trying to integrate an exception plan based on the findings of the check mentioned in the penultimate bullet, to ensure that any anomalies don’t fall to incident management, as they then might state that deployment accuracy is down to the ‘infrastructure management’ team, and resolve to do nothing with the problem – all the while users are sat there without the software they need to do their jobs. Accountability in SAM is a large and necessary part of the programme, and an aspect which will be covered in greater detail towards the end of the book.

Incident management process: A point worth noting here is that ISO19770-1 does not look to subsume ISO20000, merely to complement it. Incident management is typically bound over by varying OLAs (Operation Level Agreements) and SLAs (Service Level Agreements), and so SAM will be looking to underpin such demands to assist incident management staff in their jobs. This is very evident, not least in the last two processes covered above; deployment management (and the planning thereof) can make the job of support staff far easier in light of fault diagnosis and provision of resolution. The old adage ‘forewarned is forearmed’ is never truer than here.

As with all relationships, there is a yin and yang to consider. Incident management could impact SAM and SAM-related goals (e.g. calls for patches, hotfixes, upgrades, etc. could instigate any one of several processes previously covered). Therefore, it would be prudent for the head of SAM to sit down with the head of incident management, to establish the relationship between the two departments to see how best they can support each other, and then document such support. Equally (as with all processes), I would recommend building in a review period. Business strategy or IT strategy (not to mention IT operations) could see either department changing its own priorities, and leaving behind the aforementioned pact, or placing it under a strain for the sake of a meeting.

Problem management process: ISO19770-1 does not look to resolve problems as they might arise (per se); however, what it does seek to address is the integrity of SAM (and SAM-related assets) resulting from the analysis of problems within IT environments. So, if (for example) the deployment of a piece of software was wider and further than originally intended; then an investigation into the security and integrity of any master copies of software might be a prudent step to take. As ever, it is impossible to map the world, but the ability to think outside the box and at least have contingencies in place concerning how software is effectively controlled, will serve to underpin your knowledge of what is deployed (and what is held in reserve).

Your process should include:

• a means and method by which all SAM-related problems are recorded and classified
• problem management processes that seek to catalogue frequency, and prioritise the most important issues
• resultant causes of aforementioned problems being communicated to incident management
• resultant problem resolution plans being documented and communicated to incident management.

Retirement process: Too often, I have seen devices thrown away with little or no regard to the intellectual property that resides on hard drives. What doesn’t dawn on the minds of those doing the disposing, is that such devices could have large amounts of software on them that could be recycled. ISO19770-1 looks to ensure that a retirement process exists, and that records are maintained of any recycling taking place.

Your policy should include (as a minimum):

• an instruction to remove all software from retired hardware assets
• an identification of which software can be reused in the future
• an adherence to correct (both legal and licensable) transfer procedures should SAM-related assets be sold/bought by other parties
• a method by which all such retirements are recorded, offering traceability wherever possible.

Since the drafting of ISO19770-1, retirement has been further qualified in the minds of many people to make a distinction between retirement (i.e. software potentially available for reuse) and disposal (i.e. software that is never coming back to an organisation). At the time of this booklet going to press, ISO19770-1 made no such distinction, but you may find that your organisation will benefit greatly from having a thorough understanding of what can be reused, and what software has been condemned, never to return.

Questions/points to consider when drafting a retirement policy might include:

• Who authorises the disposal of hardware?
• Are they required to inform any software champions of this disposal?
• Who will conduct the software removal?
• How will this be vetted?
• Will the retirement of such hardware necessitate an update of the Approved Software List?
• Will the retirement of such hardware necessitate an update of the Definitive Media Library?
• Are there any cross-charge considerations to account for with the retirement?
• What is the business impact of disposing of the software?
• How will the company ensure adherence to WEEE regulations (or obtain appropriate certificates of destruction for non-EU areas)?
• Obtaining the correct transfer paperwork for software sales, mergers and acquisitions.
• If disposal/retirement is being outsourced, what kind of SLAs will your company put in place to:
  • address your own unique business requirements
  • address your ISO19770-1 requirements.