Technical requirements - Information Technology Services

High Level Requirements ­ Technical
by Lisa Gardner — last modified Oct 27, 2011 09:30 AM
This is an example, from April 2009, and is intended
as a guide for discussions with Key Stakeholers
(data/system steward, business office/functional
users, service teams ­ functional and technical). High
Level Requirements ­ Technical
by Lisa Gardner — last modified Oct 27, 2011 09:30 AM
This is an example, from April 2009, and is intended as a guide for discussions with Key
Stakeholers (data/system steward, business office/functional users, service teams ­ functional
and technical). Feel free to use in whole or in part, and modify as needed (please send
modifications to ea@ucsc.edu so that we can improve this template).
Interviews
Perform and document the interviews with Key Stakeholders
● For example: Data/System Stewards, Business Office, Service Providers, Project
Sponsor, Service Manager, etc. as applicable and useful for the project or service
● If status is not 100%, indicate in the notes if completion is necessary before beginning the
engagement (e.g., before design, before build, etc.)
date time whom to interview(ed)
(name, phone, email,
div/dept/office)
status
(% complete)
Notes

List of Questions/Common ITS Practices
During interviews, validate the following technical requirements:
● Describe the requirement (add to, remove from, or modify the list below, where
appropriate)
● Provide an example use case(s) (full use cases should be documented separately, and
are used for testing ­ unit, functional, technical, load, and user acceptance)
● Identify who requested the requirement, and what they consider is the risk of doing/not
doing
● Confirm the Ranking (cost/benefit), where
○ 1 = Must Have; a “show stopperâ€​requirement, without which the solution is
of little use or benefit
○ 2 = Preferred; if demonstrable efficiency, cost savings, or income producing; may
be deferred or canceled if unacceptable scope risk (cannot accommodate cost,
time, resources, quality)
○ 3 = Optional; Intangible or small benefits only; shall be deferred or canceled if cost
>= benefit
● Confirm the Priority, where
○ Order of completion is necessary to distinguish multiple requests/deliverables
competing for same resources, budget, and/or schedule
# requirement
use case(s)
other notes of interest
0 Confirm Data/System Steward
Contact Info
● name, email, phone,
div/dept/office
● add contact info for any
person with delegated
authority
1 Data Types & Classification
requester
risk of
doing
risk of
not
doing
ranking
priority
1a
Includes restricted or confidential
data (see IS2 andIS3)
● Use Case (example):
1099 information
containing SSN (PII,
restricted)
● Use Case (example):
Worker's comp report

●
●
●
(HIPAA, restricted)
Use Case (example):
Student home address
(FERPA, restricted)
Use Case (example):
Payment information
(PCI, restricted)
Use Case (example):
Contract information
containing vendor
proprietary data
(confidential)
1b
1c
Includes standard file types (text,
doc, xls, etc.) and/or
non­standard file types
● Use Case (example):
Excel files sent to/from
UCOP for corporate
reporting
● Use Case (example):
XML and XSD files sent
from vendor to UCSC ITS
Service Provider
Includes multimedia
● Use Case (example):
JPG, TIFF, MOV, WMP
2 Request & Account
Management
2a
Account request processing is
handled by whom (e.g.,
processing account
activation/revocation)
● Use Case (example):
Anyone can submit a
request through IT
Request.
● Use Case (example):
Only Data Steward will
submit a request through

●
IT Request.
Use Case (example):
Account management is
handled within the
business office.
2b
Who approves account requests
­ Data Steward, Bus Ofc, other
● Use Case (example):
Data steward approves
user to have access to
limited dataset vs full
dataset.
● Use Case (example):
Bus Ofc approves user to
business office data.
2c Who approves permissions ­
rwxd vs crud Are permissions
persistent or ad­hoc Are
permissions between users
and/or systems
● Use Case (example):
Data steward approves
user to have read access
to limited dataset vs full
dataset.
● Use Case (example):
Bus Ofc approves
external system to have
execute permissions for
script that process
business office data and
transmits to UCOP.
2d
Who sets and/or can modify
permissions of the directory
structure(s) and/or data file(s)
Are permissions persistent or
ad­hoc
● Use Case (example):
Process Owner sets
permissions to bus ofc

●
data and directory
structures.
Use Case (example): Bus
Ofc POC can set
one­time permissions to
bus ofc data and directory
structures when
permission process fails
or an exception request is
necessary.
2e
What do we capture in the audit
logs (system, app, database,
etc.) And, who has access to
review and/or interrogate the
audit logs, at what frequency
● Use Case (example):
Audit logs capture new
account, account change,
account revocation,
successful login
attempts, failed login
attempts, login attempts
source/destination, etc.
● Use Case (example):
Service Provider
interrogates audit logs
and submits report to
data stewards, on a
quarterly basis
3 User Communities
3a
Within UCSC and/or UC, who
can use the system and what
roles do they have
● Use Case (example):
Students have "student"
role (crud and rwxd only
their own records).
● Use Case (example): Bus
Ofc POC has "officer"
role (crud and rwxd to

●
their bus ofc group of
records).
Use Case (example): Bus
Ofc admin has "admin"
role (configures business
rules, and can
RWXD/CRUD on dev/test
and training; no RWXD
and no CRUD to stage/qa
or production).
3b
Who are the external
(non­UCSC/UC) users of the
system and what roles do they
have
●
●
●
Use Case (example):
Contractor accts with
RWXD/CRUD to
non­production systems,
duration of
implementation only.
Use Case (example):
Vendor accts with Read
access to production
system for interface
processing.
Use Case (example):
Limited acct Read
access to stage/qa that
auto­expires after
nnhours.
3b
1 REPEAT THIS AS 3a1 to
IDENTIFY IF USING GOLD vs.
BLUE vs LOCAL
Group password for
system­to­system processing
UCSC, UC, or external
source/destination

●
Use case (example):
Group pwd for ODBC
connect between UCSC
source and UCOP
destination.
3c
What tools or technologies will
clients need to access the
system
Example: Use of secure
protocols such as VPN, SSH,
SCP, SFTP
Exaple: Use of secure application
methods (such as encryption)
that don't expose data or user
information (account/pwd)
MOVE REMAINING to Security
SECTION
Will secure client be required for
access, authentication, data xfer,
etc
● Use case (example):
SSH, VPN
● Use case (example):
Shibboleth
● Use case (example):
SCP/SFTP
3d
COMBINE WITH 3a (and delete
3d)
Accessible by other UC system
(sister campus and/or UCOP),
and what permissions
● Use Case (example):
allow RSYNC between

●
UCSC and UCOP
systems, utilizing VPN
connection, for file copy
to/from.
Use Case (example):
allow manual data xfer via
SCP/SFTP between
UCSC and Vendor
system, to be launched
by vendor system.
3e
COMBINE WITH 3a (and delete
3e)
Limit usage to
business/administrative
● Use Case (example):
Administrative Bus Ofc
only.
3f
Anonymous file drop/retrieve
● Use Case (example):
Allow Bus Ofc POC at
UCOP to put files on
system.
4 Help & User Support
4a
NEEDS WORK
Who provides user support for
setup/removal of connection,
bugs or problems, directory
structure/file standards, and
permission problems AND
HOW
Incident vs. Service Request vs.
Information Request
Service Now functionality may
address this

How do you support external
users
●
●
●
Use Case (example):
User submits request for
help via IT Request; ticket
is assigned to ITS
Service Provider.
Use Case (example):
User submits request for
help via IT Request; ticket
is assigned to Bus Ofc.
Use Case (example):
User contacts Bus Ofc to
request help, and Bus
Ofc responds (ITS is not
part of support process).
4c
Who provides user
documentation, faqs, and
training
● Use Case (example):
data steward will create
user guides and faqs, and
make available to users,
training is not provided.
● Use Case (example): ITS
will create technician
guides and faqs, and
provide for technician
training.
5 Directory and/or Data
Structures and File Naming
standards as they affect the
UX or UI
5a
What is the directory/data
structure needed to inform
design solution, and based on
customer requirements

5b
What is the file naming
convention needed to inform
design solution, and based on
customer requirements
6 Technical/Operational
6a
6b
Service Availability (pick one)
● Tier 3 ­ 24x7x365,
excluding maintenance
window, incident
response, and cold
backups, see also 7b
● Tier 2 ­ M­F 7­7,
excluding campus
holidays or closures,
maintenance window,
incident response, cold
backups, see also 7b
● Tier 1 ­ M­F 8­5,
excluding campus
holidays or closures,
maintenance window,
incident response, cold
backups, see also 7b
Maintenance Window (which
may be defined to occur outside
of business/service hours):
1. Frequency (pick one or
more): Daily, Weekly,
Monthly, Qrtly, Yearly
2. Day of Week (pick one or
more, must be within
Service Availability Tier):
MTuWThFSaSu
3. Time of Day: based on
Tier 1 or 2 Service
Availability; if Tier 3 pick
time range (must start
after, and finish before)
4. Exception: Security
patches will be applied

outside the regular
maintenance window,
depending on
risk/vulnerability, and/or
as directed by ITS
Security or campus
Information Security
Officer (ISO)
6c
6d
Incident/Response:
1. Response within eight
business hours of receipt
based on Service
Availability Tier (see #6a,
above), or Service Level
Agreement (see #7,
below)
2. Repairs may be effected
during business hours
and pending outage
tolerance of steward
○ Mean Time To
Repair (MTTR) is
dependent on
completion of root
cause analysis,
identification and
execution of
mitigation options,
may be limited by
vendor
maintenance
agreement
3. Repairs may be
short­term (e.g., bring
system/service online,
but additional repair work
is required, and will be
scheduled as needed)
SHAWN TO WORDSMITH
Privileged Access (Application,

Database, and System
Administrators)
1. Will adhere to service
provider guidelines
2. Will use secure access
methods (SSH, VPN, or
other approved method)
3. Will include account and
access information within
quarterly report to data
stewards (see 2e, above)
6e
LISA TO WORDSMITH
remaining of 6 with Eric Keisler
Where Hosted Who supports
the hosting What hosting
functions are included
Use Case: If System will be
housed in the ITS Data Center or
another ITS­supported facility,
consider the following ­
○ ITS Administrators
will manage the
systems
(application,
database,
hardware and
operating system)
○ Includes
monitoring of
system health,
and alert when
performance
targets degrade
■ Confirm if
non­ITS
service
provider
will receive
alerts

●
○ Hardware refresh
occurs on a
five­year life­cycle,
or as otherwise
identified by the
vendor (typically
end­of­life
notifications)
○ Software
life­cycles are
performed per
vendor distribution
and/or end­of­life
notifications
Log Management
○ Logs (system,
app, database,
etc.) may capture
the following data
(including but not
limited to): new
account, account
change, account
revocation,
successful login
attempts, failed
login attempts,
login attempt
source/destination
; activity (get/put,
copy, move,
remove, execute);
duration of activity;
web page
source/destination
○ Administrators
periodically review
and/or interrogate
the audit logs,
including post
incident to support
root cause and/or

●
●
statistical analysis
○ Logs may be
made available to
ITS Security for
breach
investigation
and/or forensics
○ Results of log
reviews may be
made available to
Data/System
Steward and/or
other authorities,
upon request and
per policy
System will adhere to UC
BFB IS series (IS3 and
IS12)
Criteria for Design
Review, before
production build occurs
○ Class 3 or above
○ Spans multiple
units, or single
unit budgetary
discretion
○ High or unknown
risk
○ High political value
○ New or unfamiliar
technology
○ Upon request
6f
Fault Tolerance and Disaster
Recovery (see IS12)
● Consider redundancy of
system components
(reduction of
single­points­of failure)
where feasible
● Minimum number of
environments = two

●
(dev/test and prod)
○ If "necessary" or
"essential" then
minimum number
of environments =
3 (dev/test,
stage/qa, prod)
(where stage/qa
can accurately
predict production
behavior)
If "essential"
○ Stage/qa
environment must
be equal to prod
(e.g., use as an
alternative host in
the event that
production host
fails and is
irreparable)
■ Consider
automated
failover vs.
manual
failover,
depending
on
feasibility
○ Consider a
remote location
for data and/or
system replication
(may place
stage/qa in
remote location)
○ Establish and
perform periodic
disaster recovery
exercises
6g
Authentication

●
●
For UCSC access
(students, faculty, staff),
pending technical
feasibility
○ Utilize Identity
Management
(IDM) Shibboleth
or LDAP­Bind, or
○ Utilize local
authentication
For non­UCSC access
○ Establish "sundry"
accounts within
IDM, or
○ Utilize local
account
management
6h
Storage Management
● Locally­attached vs. SAN
vs NAS
● Compression, duplication
(RAID)
● Capacity (GB vs TB)
● Quotas and/or usage
○ single reminder
when at 75%
○ weekly reminder
when >= 80%
○ daily reminder
when >= 90%
● Data "pruning" performed
periodically
○ specify time­span
since last update,
when data is
considered aged
○ specify if aged
data can be
pruned
automatically
○ reminder and/or

notification of
pruning
Data Security
● Must be secure deleted
● Storage device must be
secure destroyed when
retired, recycled, or
6i
Backups
1. Specify includes and
excludes (e.g., directory
structure & permissions,
user/data files,
application, database,
operating system, etc.)
2. Specify frequency for
incremental and full
(typically nightly
incremental, weekly full)
3. Specify backup media
(typically to disc then tape
within same 24­hour
period)
4. Specify backup retention
period other than default
(see
http://its.ucsc.edu/policies
/backup.html for default
term)
○
Consider
restoration
feasibility if
retention period is
longer than 3
years (e.g., you
will need to
assure restoration
capabilities for the
life of the retention
period, for each
backup that is
maintained)

7 Service
○ Consider default
retention period
may be sufficient
for those systems
that retain all
historical data
within the
transactional
system versus
those that archive
data outside of the
transactional
system
5. Specify onsite and offsite
stores (typically cycled
weekly into onsite ITS
vault, then 2nd week
offsite to Iron Mountain,
current as of Oct 2011
and subject to change)
6. Specify recycle of backup
media (typically quarterly)
○ Secure delete of
backup media
before re­entry
into backup cycle
(regardless of IS3)
7. Periodic restore test
a. Perform once
prior to production
deployment,
yearly thereafter
(minimum)
b. Perform tests for
single file and full
system restores
7a
Utilize ITS and Campus Service
Level Agreement(SLA) or
service­unique SLA (template

available)
7b
7c
7d
Utilize common Operations Level
Agreement (OLA) or
service­unique OLA (template
available)
ITS Practices
● Request intake process
and procedures
● Project management
methodology (andtoolkit)
● SDLC for design, build,
test, deploy (see
alsoIS10)
● Service Management
Toolkit
○ Incident and
Change
Management
processes and
procedures
● Security Policies
● Inventory tracking
● Billing and Recharge
Configuration and Technical
Documentation and Procedures
● Developed, maintained,
and resides with
technician group
Questions
1. Besides business offices, who else needs access to the new system/service and/or
data
2. What is the existing legacy business process and/or system Can it be
upgraded/enhanced or must it be replaced/retired in full or in part
3. What is ITS current service commitment regarding the existing legacy business process
and/or system
4.

Assumptions
1. Business office will perform fit­gap (comparison of legacy business process vs. design
solution); gaps will be accepted (implies business process re­engineering), rejected
(implies mitigation such as re­engineering technical or business processes, and/or
bolt­ons, to address the gap), or transferred (defer mitigation as future enhancement
after deployment of solution).
2. Full cost a new system/service will be charged to the data/system steward, business
office, and/or shared across the user community.
3. If ITS SMT does not approve the new system/service, existing legacy business process
and/or system will remain unchanged.
4.
Acronym Soup
see also ITS Glossary of Policy­Related Terms
● BFB IS = Business and Finance Bulletins, Information Systems
● CRUD = Create, Read, Update, Delete
● CruzID = user ID managed by ITS Identity Management service
● EOL = end of life
● FERPA = Family Educational Rights and Privacy Act
● MTTR = Mean Time to Response/Repair/Restore (duration)
● OLA = Operations Level Agreement
● PCI = Payment Card Industry
● PII = Personal Identity Information
● RWXD = Read, Write, Execute, Delete
● SDLC = Systems Development Life Cycle
● SLA = Service Level Agreement
● SMT = Senior Management Team (comprised of ITS VCIT and Directors)
● SSH = Secure Shell
● VPN = Virtual Private Network
Feel free to use in whole or in part, and modify as needed (please send modifications to
ea@ucsc.edu so that we can improve this template).
Interviews
Perform and document the interviews with Key Stakeholders
● For example: Data/System Stewards, Business Office, Service Providers, Project
Sponsor, Service Manager, etc. as applicable and useful for the project or service
● If status is not 100%, indicate in the notes if completion is necessary before beginning the

engagement (e.g., before design, before build, etc.)
date time whom to interview(ed)
(name, phone, email,
div/dept/office)
status
(% complete)
Notes
List of Questions/Common ITS Practices
During interviews, validate the following technical requirements:
● Describe the requirement (add to, remove from, or modify the list below, where
appropriate)
● Provide an example use case(s) (full use cases should be documented separately, and
are used for testing ­ unit, functional, technical, load, and user acceptance)
● Identify who requested the requirement, and what they consider is the risk of doing/not
doing
● Confirm the Ranking (cost/benefit), where
○ 1 = Must Have; a “show stopperâ€​requirement, without which the solution is
of little use or benefit
○ 2 = Preferred; if demonstrable efficiency, cost savings, or income producing; may
be deferred or canceled if unacceptable scope risk (cannot accommodate cost,
time, resources, quality)
○ 3 = Optional; Intangible or small benefits only; shall be deferred or canceled if cost
>= benefit
● Confirm the Priority, where
○ Order of completion is necessary to distinguish multiple requests/deliverables
competing for same resources, budget, and/or schedule
# requirement
use case(s)
other notes of interest
0 Confirm Data/System Steward
Contact Info
● name, email, phone,
div/dept/office
● add contact info for any
requester
risk of
doing
risk of not
doing
ranking
priority

person with delegated
authority
1 Data Types & Classification
1
a
1
b
1
c
Includes restricted or confidential
data (see IS2 andIS3)
● Use Case (example): 1099
information containing SSN
(PII, restricted)
● Use Case (example):
Worker's comp report (HIPAA,
restricted)
● Use Case (example): Student
home address (FERPA,
restricted)
● Use Case (example):
Payment information (PCI,
restricted)
● Use Case (example):
Contract information
containing vendor proprietary
data (confidential)
Includes standard file types (text, doc,
xls, etc.) and/or non­standard file
types
●
●
Use Case (example): Excel
files sent to/from UCOP for
corporate reporting
Use Case (example): XML
and XSD files sent from
vendor to UCSC ITS Service
Provider
Includes multimedia
● Use Case (example): JPG,
TIFF, MOV, WMP
2 Request & Account Management
2
a
Account request processing is
handled by whom (e.g., processing

account activation/revocation)
● Use Case (example): Anyone
can submit a request through
IT Request.
● Use Case (example): Only
Data Steward will submit a
request through IT Request.
● Use Case (example): Account
management is handled
within the business office.
2
b
2
c
2
d
Who approves account requests ­
Data Steward, Bus Ofc, other
● Use Case (example): Data
steward approves user to
have access to limited
dataset vs full dataset.
● Use Case (example): Bus
Ofc approves user to
business office data.
Who approves permissions ­ rwxd vs
crud Are permissions persistent or
ad­hoc Are permissions between
users and/or systems
● Use Case (example): Data
steward approves user to
have read access to limited
dataset vs full dataset.
● Use Case (example): Bus
Ofc approves external system
to have execute permissions
for script that process
business office data and
transmits to UCOP.
Who sets and/or can modify
permissions of the directory
structure(s) and/or data file(s) Are
permissions persistent or ad­hoc
● Use Case (example):
Process Owner sets
permissions to bus ofc data

●
and directory structures.
Use Case (example): Bus Ofc
POC can set one­time
permissions to bus ofc data
and directory structures when
permission process fails or an
exception request is
necessary.
2
e
What do we capture in the audit logs
(system, app, database, etc.) And,
who has access to review and/or
interrogate the audit logs, at what
frequency
● Use Case (example): Audit
logs capture new account,
account change, account
revocation, successful login
attempts, failed login
attempts, login attempts
source/destination, etc.
● Use Case (example): Service
Provider interrogates audit
logs and submits report to
data stewards, on a quarterly
basis
3 User Communities
3
a
Within UCSC and/or UC, who can
use the system and what roles do
they have
● Use Case (example):
Students have "student" role
(crud and rwxd only their own
records).
● Use Case (example): Bus Ofc
POC has "officer" role (crud
and rwxd to their bus ofc
group of records).
● Use Case (example): Bus Ofc
admin has "admin" role
(configures business rules,

and can RWXD/CRUD on
dev/test and training; no
RWXD and no CRUD to
stage/qa or production).
3
b
Who are the external
(non­UCSC/UC) users of the system
and what roles do they have
●
●
●
Use Case (example):
Contractor accts with
RWXD/CRUD to
non­production systems,
duration of implementation
only.
Use Case (example): Vendor
accts with Read access to
production system for
interface processing.
Use Case (example): Limited
acct Read access to stage/qa
that auto­expires after
nnhours.
3
b
1
REPEAT THIS AS 3a1 to IDENTIFY
IF USING GOLD vs. BLUE vs LOCAL
Group password for
system­to­system processing
UCSC, UC, or external
source/destination
● Use case (example): Group
pwd for ODBC connect
between UCSC source and
UCOP destination.
3
c
What tools or technologies will clients
need to access the system
Example: Use of secure protocols
such as VPN, SSH, SCP, SFTP
Exaple: Use of secure application

methods (such as encryption) that
don't expose data or user information
(account/pwd)
MOVE REMAINING to Security
SECTION
Will secure client be required for
access, authentication, data xfer,
etc
● Use case (example): SSH,
VPN
● Use case (example):
Shibboleth
● Use case (example):
SCP/SFTP
3
d
COMBINE WITH 3a (and delete 3d)
Accessible by other UC system
(sister campus and/or UCOP), and
what permissions
● Use Case (example): allow
RSYNC between UCSC and
UCOP systems, utilizing VPN
connection, for file copy
to/from.
● Use Case (example): allow
manual data xfer via
SCP/SFTP between UCSC
and Vendor system, to be
launched by vendor system.
3
e
COMBINE WITH 3a (and delete 3e)
Limit usage to
business/administrative
● Use Case (example):
Administrative Bus Ofc only.

3
f
Anonymous file drop/retrieve
● Use Case (example): Allow
Bus Ofc POC at UCOP to put
files on system.
4 Help & User Support
4
a
NEEDS WORK
Who provides user support for
setup/removal of connection, bugs or
problems, directory structure/file
standards, and permission
problems AND HOW
Incident vs. Service Request vs.
Information Request
Service Now functionality may
address this
How do you support external users
●
●
●
Use Case (example): User
submits request for help via IT
Request; ticket is assigned to
ITS Service Provider.
Use Case (example): User
submits request for help via IT
Request; ticket is assigned to
Bus Ofc.
Use Case (example): User
contacts Bus Ofc to request
help, and Bus Ofc responds
(ITS is not part of support
process).
4
c
Who provides user documentation,
faqs, and training
● Use Case (example): data
steward will create user
guides and faqs, and make

●
available to users, training is
not provided.
Use Case (example): ITS will
create technician guides and
faqs, and provide for
technician training.
5 Directory and/or Data Structures
and File Naming standards as they
affect the UX or UI
5
a
5
b
What is the directory/data structure
needed to inform design solution, and
based on customer requirements
What is the file naming convention
needed to inform design solution, and
based on customer requirements
6 Technical/Operational
6
a
6
b
Service Availability (pick one)
● Tier 3 ­ 24x7x365, excluding
maintenance window, incident
response, and cold backups,
see also 7b
● Tier 2 ­ M­F 7­7, excluding
campus holidays or closures,
maintenance window, incident
response, cold backups, see
also 7b
● Tier 1 ­ M­F 8­5, excluding
campus holidays or closures,
maintenance window, incident
response, cold backups, see
also 7b
Maintenance Window (which may be
defined to occur outside of
business/service hours):
1. Frequency (pick one or more):
Daily, Weekly, Monthly, Qrtly,
Yearly

2. Day of Week (pick one or
more, must be within Service
Availability Tier):
MTuWThFSaSu
3. Time of Day: based on Tier 1
or 2 Service Availability; if Tier
3 pick time range (must start
after, and finish before)
4. Exception: Security patches
will be applied outside the
regular maintenance window,
depending on
risk/vulnerability, and/or as
directed by ITS Security or
campus Information Security
Officer (ISO)
6
c
Incident/Response:
1. Response within eight
business hours of receipt
based on Service Availability
Tier (see #6a, above), or
Service Level Agreement (see
#7, below)
2. Repairs may be effected
during business hours and
pending outage tolerance of
steward
○ Mean Time To Repair
(MTTR) is dependent
on completion of root
cause analysis,
identification and
execution of mitigation
options, may be
limited by vendor
maintenance
agreement
3. Repairs may be short­term
(e.g., bring system/service
online, but additional repair
work is required, and will be

scheduled as needed)
6
d
6
e
SHAWN TO WORDSMITH
Privileged Access (Application,
Database, and System
Administrators)
1. Will adhere to service provider
guidelines
2. Will use secure access
methods (SSH, VPN, or other
approved method)
3. Will include account and
access information within
quarterly report to data
stewards (see 2e, above)
LISA TO WORDSMITH remaining of
6 with Eric Keisler
Where Hosted Who supports the
hosting What hosting functions are
included
Use Case: If System will be housed
in the ITS Data Center or another
ITS­supported facility, consider the
following ­
○ ITS Administrators will
manage the systems
(application, database,
hardware and
operating system)
○ Includes monitoring of
system health, and
alert when
performance targets
degrade
■ Confirm if
non­ITS
service
provider will
receive alerts

●
○ Hardware refresh
occurs on a five­year
life­cycle, or as
otherwise identified by
the vendor (typically
end­of­life
notifications)
○ Software life­cycles
are performed per
vendor distribution
and/or end­of­life
notifications
Log Management
○ Logs (system, app,
database, etc.) may
capture the following
data (including but not
limited to): new
account, account
change, account
revocation, successful
login attempts, failed
login attempts, login
attempt
source/destination;
activity (get/put, copy,
move, remove,
execute); duration of
activity; web page
source/destination
○ Administrators
periodically review
and/or interrogate the
audit logs, including
post incident to
support root cause
and/or statistical
analysis
○ Logs may be made
available to ITS
Security for breach
investigation and/or

●
●
forensics
○ Results of log reviews
may be made
available to
Data/System Steward
and/or other
authorities, upon
request and per policy
System will adhere to UC
BFB IS series (IS3 and IS12)
Criteria for Design Review,
before production build occurs
○ Class 3 or above
○ Spans multiple units,
or single unit
budgetary discretion
○ High or unknown risk
○ High political value
○ New or unfamiliar
technology
○ Upon request
6
f
Fault Tolerance and Disaster
Recovery (see IS12)
● Consider redundancy of
system components
(reduction of single­points­of
failure) where feasible
● Minimum number of
environments = two (dev/test
and prod)
○ If "necessary" or
"essential" then
minimum number of
environments = 3
(dev/test, stage/qa,
prod) (where stage/qa
can accurately predict
production behavior)
● If "essential"
○ Stage/qa environment
must be equal to prod

○
○
(e.g., use as an
alternative host in the
event that production
host fails and is
irreparable)
■ Consider
automated
failover vs.
manual
failover,
depending on
feasibility
Consider a remote
location for data and/or
system replication
(may place stage/qa in
remote location)
Establish and perform
periodic disaster
recovery exercises
6
g
6
h
Authentication
● For UCSC access (students,
faculty, staff), pending
technical feasibility
○ Utilize Identity
Management (IDM)
Shibboleth or
LDAP­Bind, or
○ Utilize local
authentication
● For non­UCSC access
○ Establish "sundry"
accounts within IDM,
or
○ Utilize local account
management
Storage Management
● Locally­attached vs. SAN vs
NAS
● Compression, duplication

(RAID)
● Capacity (GB vs TB)
● Quotas and/or usage
○ single reminder when
at 75%
○ weekly reminder when
>= 80%
○ daily reminder when
>= 90%
● Data "pruning" performed
periodically
○ specify time­span
since last update,
when data is
considered aged
○ specify if aged data
can be pruned
automatically
○ reminder and/or
notification of pruning
Data Security
● Must be secure deleted
● Storage device must be
secure destroyed when
retired, recycled, or
6
i
Backups
1. Specify includes and excludes
(e.g., directory structure &
permissions, user/data files,
application, database,
operating system, etc.)
2. Specify frequency for
incremental and full (typically
nightly incremental, weekly
full)
3. Specify backup media
(typically to disc then tape
within same 24­hour period)
4. Specify backup retention
period other than default (see
http://its.ucsc.edu/policies/bac

kup.html for default term)
○ Consider restoration
feasibility if retention
period is longer than 3
years (e.g., you will
need to assure
restoration capabilities
for the life of the
retention period, for
each backup that is
maintained)
○ Consider default
retention period may
be sufficient for those
systems that retain all
historical data within
the transactional
system versus those
that archive data
outside of the
transactional system
5. Specify onsite and offsite
stores (typically cycled weekly
into onsite ITS vault, then 2nd
week offsite to Iron Mountain,
current as of Oct 2011 and
subject to change)
6. Specify recycle of backup
media (typically quarterly)
○ Secure delete of
backup media before
re­entry into backup
cycle (regardless of
IS3)
7. Periodic restore test
a. Perform once prior to
production
deployment, yearly
thereafter (minimum)
b. Perform tests for
single file and full
system restores

7 Service
7
a
7
b
7
c
7
d
Utilize ITS and Campus Service Level
Agreement(SLA) or service­unique
SLA (template available)
Utilize common Operations Level
Agreement (OLA) or service­unique
OLA (template available)
ITS Practices
● Request intake process and
procedures
● Project management
methodology (andtoolkit)
● SDLC for design, build, test,
deploy (see alsoIS10)
● Service Management Toolkit
○ Incident and Change
Management
processes and
procedures
● Security Policies
● Inventory tracking
● Billing and Recharge
Configuration and Technical
Documentation and Procedures
● Developed, maintained, and
resides with technician group
Questions
1. Besides business offices, who else needs access to the new system/service and/or
data
2. What is the existing legacy business process and/or system Can it be
upgraded/enhanced or must it be replaced/retired in full or in part
3. What is ITS current service commitment regarding the existing legacy business process
and/or system
4.

Assumptions
1. Business office will perform fit­gap (comparison of legacy business process vs. design
solution); gaps will be accepted (implies business process re­engineering), rejected
(implies mitigation such as re­engineering technical or business processes, and/or
bolt­ons, to address the gap), or transferred (defer mitigation as future enhancement
after deployment of solution).
2. Full cost a new system/service will be charged to the data/system steward, business
office, and/or shared across the user community.
3. If ITS SMT does not approve the new system/service, existing legacy business process
and/or system will remain unchanged.
4.
Acronym Soup
see also ITS Glossary of Policy­Related Terms
● BFB IS = Business and Finance Bulletins, Information Systems
● CRUD = Create, Read, Update, Delete
● CruzID = user ID managed by ITS Identity Management service
● EOL = end of life
● FERPA = Family Educational Rights and Privacy Act
● MTTR = Mean Time to Response/Repair/Restore (duration)
● OLA = Operations Level Agreement
● PCI = Payment Card Industry
● PII = Personal Identity Information
● RWXD = Read, Write, Execute, Delete
● SDLC = Systems Development Life Cycle
● SLA = Service Level Agreement
● SMT = Senior Management Team (comprised of ITS VCIT and Directors)
● SSH = Secure Shell
● VPN = Virtual Private Network