►
From YouTube: Security Policy JTBD 2023
Description
This video is a walkthrough of the summarized insights gained from UX research on security policies for GitLab.
https://gitlab.com/gitlab-org/ux-research/-/issues/2223
A
A
I
think
the
difference
between
those
is
just
a
difference
in
perspective
in
the
organization
whether
they're,
like
people
focused
or
just
kind
of
top-down
business
focused,
but
the
needs
for
those
jobs
are
to
increase
the
adoption
of
the
organization's
assets
to
the
compliance
requirements,
to
reduce
the
likelihood
of
a
legal
and
financial
threat
to
the
organization
to
increase
awareness
of
the
security
standards
among
the
developers.
So
all
of
those
are
kind
of
the
needs
and
the
reasons
to
do
to
create
a
security
policy.
A
And
then
we
can
kind
of
look
into
the
actual
steps
of
that
and
I'll
just
go
over.
The
excuse
me,
the
higher
level
ones
right
here.
So
first
they
gather
the
security
requirements
and
then
they
have
to
understand
those
requirements
and
usually
organize
them
among
commonalities
or
like
similarities
in
stakeholders
or
whoever
is
going
to
be
like
touching
that
specific
aspect.
A
So
they
organize
those
requirements
and
then
they
scope
out
the
language
and
kind
of
consider
the
non-technical
stakeholders
that
might
be
involved
versus
the
technical
stakeholders
and
figure
out
what
type
of
language
the
policy
needs
to
be
in
and
then
they
actually
write
the
security
policy
language.
This
is
sometimes
done
in
collaboration
with
a
legal
team
or
security
stakeholders.
It
depends
on
the
size
and
organize
and
maturity
of
the
organization.
There
are
usually
multiple
people
who
do
collaborate
at
that
point,
but
the
policy
Creator
is
the
person
responsible
for
actually
writing
the
language.
A
We
would
put
it
in
our
handbook,
so
everybody
can
see
it,
but
another
organization
might
have
a
slightly
different
system
and
then
the
last
process,
or
the
last
step
in
the
job,
is
to
monitor
the
security
policies
and
to
follow
up
to
make
sure
everyone
understands.
That's
not
100
consistent
throughout
everywhere,
but
it
is.
A
But
I
would
consider
like
the
typical
standard,
because
eventually
the
policy
creators
do
have
to
go
back
and
make
sure
that
the
policies
are
actually
being
followed
and
making
sure
that
everything's,
okay
and
the
monitor
the
policies
just
the
step
in
that
process.
Eventually
so
then
we
can
go
to
the
circumstances
when
a
policy
Creator
would,
you
know,
create
a
policy
and
do
all
of
this
it'd
be
when
a
new
legal
or
customer
requirement
appears.
A
So
a
legal
requirement
would
probably
come
from
their
industry,
sock,
2
or
gdpr
stuff,
like
that,
whereas
a
customer
requirement
might
be
an
Enterprise
company,
has
a
specific
customer
that
has
a
very
specific
set
of
requirements
that
they
need
for
their
data
because
they
have
a
higher
security
maturity.
So
then
they,
a
B2B
contract,
might
specifically
state
to
you
know
a
couple
requirements
for
security.
A
They
also
might
change
or
update
security
policies
if
there's
a
security
breach
either
internal
or
external
kind
of
depends
on
the
company.
Obviously,
internal
is
always
a
big
alarm.
If
there's
an
internal
security,
threader
or
something
happens,
something
is
exposed,
but
I
had
talking
to
some
people-
external
or
you
know,
Marketplace
breaches
could
occur
and
that
could
trigger
an
internal
change
in
the
company.
So,
like
a
leader
in
the
company
could
see
that
something
happened
for
another
company
and
say
we
want
to
avoid
that.
A
So
that's
what
would
happen
and
then
that
kind
of
leads
to
the
next
circumstance
which
is
to
due
to
internal
culture
shifts.
So
that
could
be
because
a
company
is,
however,
old
and
they
look
at
their
standards
and
they
want
to
become
a
leader
in
the
marketplace.
So
then
they
try
to
you
know,
increase
their
maturity
and
that's
just
like
entirely
internally
driven
the
emotional
elements
of
this
job
were
really
only
so
understanding
the
requirements
can
be
very
time
consuming.
A
A
Just
any
of
that
process
can
be
tiresome,
not
just
like
actually
making
sure
people
are
adopting
the
security
policies
so
on
the
next
episode,
the
next
job,
in
like
a
logical
order
that
we
found
was
to
implement
security
controls
in
the
organization's
asset
and
the
needs
for
this
were
to
reduce
the
likelihood
of
a
legal
or
financial
threat
and
to
increase
the
compliance
of
the
organization's
assets
to
the
security
policy.
So,
basically,
this
is
when
a
new
security
policy
is
created
or
a
change
to
a
security
policy
happens.
A
They
sometimes
might
meet
with
technical
managers
to
make
sure
that
they
understand
everything,
because
the
developers
and
those
the
ICS
under
those
managers
are
the
people
who
the
security
control
is
actually
going
to
be
touching.
So
they
make
sure
that
everything
makes
sense
for
them
and
it
fits
into
the
developer's.
Workflow
is
a
big
priority,
so
then
they
go
ahead
and
actually
implement
the
security
control.
So
it
could
be.
This
is
the
implementation
of
the
control,
as
well
as
the
deployment
of
the
control
it.
A
They
are
two
separate
things,
but
they
happen
at
the
same
time
and
usually
in
the
same
conversation.
So
the
deployment
of
a
control
could
be
saying
if
you
want
a
certain
scanner
run.
Every
time
a
merge
request
is
created
where
the
configure
of
the
control
could
be
what
that
scanner
is
specifically
looking
for
in
the
merge
request.
A
So
both
of
those
are
configured
and
implemented,
and
then
it's
a
those
controls
are
validated
using
a
test,
usually
in
a
test
environment
or
a
local
environment,
something
that's
not
touching
production
at
all
and
to
then
they
meet
with
like
those
stakeholders
and
make
sure
everything
makes
sense
from
the
output
and
then
they
go
and
deploy
it
and
then
monitor
everything
actually
I'm.
Sorry,
this
should
be
deploy
security
tool.
A
There
we
go
so
then
they
deploy
the
security
tool
and
then
we
can
go
to
the
aspirational
jobs
on.
This
were
pretty
interesting,
two
like
aspirational
jobs,
but
not
necessarily
aspirational
for
all
of
these
jobs.
It's
just
for
this
specific
job
statement
would
be
to
have
the
ability
to
monitor
all
of
the
organization's
assets
just
having
that
ability
was
talked
about
multiple
times
in
the
interview
for
almost
everybody
and
then
another
thing
that
was
brought
up
was
to
keep
records
of
the
compliance.
A
This
is
to
prepare
for
internal
audits,
I
asked
we
had
12
people
and
every
single
person
said
that
their
organization
conducts
security
audits,
I
believe
not
all
of
them
were
because
of
a
legal
requirement,
but
because
of
a
customer
requirement
or
one
of
the
other
requirements
that
we
said
above
so
because
of
those
audits.
It
is
sometimes
it
would
be
easier
and
it
would
be
an
aspiration
for
those
Crea
for
the
implementers
to
keep
the
records
of
everything.
A
So
the
last
step
to
kind
of
lead
into
that
is
to
the
job
was
to
ensure
the
organization's
assets
are
compliant
with
those
security
policies.
So
this
is,
after
a
policy,
was
implemented
and
created
and
in
the
organization's
workflow,
and
then
it's
a
security
or
a
policy
insurer,
but
usually
it's
also.
It's
also
going
to
be
a
security
professional
going
in
and
making
sure
that
the
controls
are
working
properly.
They
are
exhaustive
and
complete
and
they
are
being
remediated.
A
Basically,
they
they
want
a
place
to
see
the
organization's
assets
and
not
just
an
individual
repositories.
Assets
I
also
asked
the
state
the
people
I
interviewed,
are
just
the
later
half
actually
because
it
was
when
we
realized.
We
should
ask
how
large
or
how
many
repositories
they're
in
charge
of
securing
and
the
range
was
from
30
to
a
thousand.
A
Multiple
people
said
hundreds
of
repositories
that
they're
in
charge
of
securing,
so
it
is
all
of
these
jobs
are
in
the
scope
of
the
entire
organization
or
at
the
very
least,
the
organization's
assets
that
they
care
about
that
touch
production.
Typically,
we
can
see
up
here
that
the
one
of
the
clarifiers
is
before
it
touches
production,
so
that
is
a
clarifier
that
is
very
specific
in
that
instance,
but
it
could
also
apply
to
generally
the
organization's
assets
as
a
whole
that
they
care
about.
A
The
circumstances
are
pretty
much
similar
to
what
I
said
before
Was
preparing
to
conduct
an
audit
or
after
a
security
breach,
but
one
of
the
interesting
things
that
came
up
ever
almost
everyone
I
can
check
actually
how
many
people
said,
but
manually
checking.
Every
single
repository
was
the
most
common
Insight
I
had
one
two
three
four
five
six
seven
people
out
of
12
explicitly
said
that
the
most
frustrating
part
of
their
process
was
checking
ever
Pros
every
repository
individually.
A
A
So
we
kind
of
found
early
on
that
we
may
use
like
the
language
enforce
security
policies,
but
that
is
an
aspirational
job,
because
the
users
cannot
literally
do
that.
There
is
no
way
for
them
to
actually
enforce
anything.
So
what
they
do
instead
is
first
they
create
the
policies.
Then
they
implement
the
policies
and
then
they
check
to
ensure
that
the
assets
are
compliant.
A
If
we
wanted
to
truly
say
that
we
are
able,
you
know
that
a
person
is
able
to
enforce,
then
there's
two
I
think
there
are
probably
two
steps
missing
here,
which
is
to
understand
the
remediation
path
when
a
non-compliant
object
is
found
and
then
to
actually
remediate
it
and
go
ahead
and
solve
it.
So
those
two
things
are
kind
of
missing
here
and
that's
one
of
the
reasons
why
this
is
really
an
aspirational
job
and
the
users
are
only
doing
these
these
jobs
and
the
micro
in
like
the
lower
level
jobs
so
yeah.
A
If
you
have
any
questions
on
anything
or
if
you
want
to
go
into
some
of
the
specifics,
I
will
share
this
mural
and
you
can
see
all
of
the
data
over
here.
It
is
I
guess
from
right
to
left
so
I
apologize.
The
data
on
the
right
is
raw
and
is
is
more
raw
rather
is
coded
directly
from
the
interviews.
This
is
data
gathered
from
all
of
this
data
and
then
this
is
the
hierarchy
level.
A
In
the
large
picture
of
of
this
job
statement,
data,
so
I
will,
like
I,
said,
I'm
going
to
be
gone
for
a
week
when
I
come
back.
I
will
update
the
handbook
page
and
continue
summarizing
the
stuff
and
surfacing
all
the
insights
in
a
way
that
we
need,
because
I
want
to
create
the
user
stories,
to
link
the
circumstances
and
the
job
statements
and
the
needs,
so
I
will
be
doing
all
of
that
when
I
get
back.
A
But
I
wanted
this
to
be
a
good
time
for
anybody
to
try
to
understand
any
of
this
see
what
we
learned
and
maybe
what
you
expected
or
what
you
didn't
expect.
If
you
think
we
should
change
anything
in
here,
if
something
doesn't
seem
quite
right
or
you
don't
really
understand
it,
I'm
totally
open
to
changing
something.
It's
just
a
conversation.
We
need
to
have
to
make
sure
that
the
Insight
still
makes
sense
from
the
user's
perspective
and
your
perspective,
because
I
don't
always
have
all
of
the
context.